* review-checklist: don't lose a reviewer who only left comments
GitHub un-requests a reviewer the instant they submit any review,
including a comment-only one from batching several inline comments into
a single submission — not just Approve/Request-changes. Unlike a stale
approval, this never produces a DISMISSED transition, so the checklist
had no way to tell "abandoned the area" apart from "still reviewing,
just hasn't finished yet."
This silently dropped the reviewer's mention from the checklist display
the moment they left comments, and risked the next push's additive-fill
picker handing their area to a completely different load-balanced
reviewer (observed on PR #6645: jhendersonHDF's batched review comments
repeatedly vanished him from src/test's rows mid-review).
Track a sticky area assignee as still engaged whenever they have no
APPROVED/CHANGES_REQUESTED/DISMISSED review on record, regardless of
whether GitHub currently lists them as requested, and use that in the
read-only display path, resolveAreaPicks, and the additive-fill picker.
* draft-pr-policy: a checked keepalive checkbox is real activity too
lastRealActivityAt() deliberately ignores bot comments so a metadata-only
bump can't dodge the staleness check forever. But checking the "Still
working on this" checkbox is an edit to the bot's own keepalive comment,
not a new comment of the human's own — its author stays
github-actions[bot], so the edit was invisible to the activity check too.
Confirming via the checkbox removed the label and posted "Thanks for
confirming" without ever moving the underlying 60-day clock, so the very
next scheduled run saw the same stale last-activity timestamp and
immediately re-flagged it — contradicting the checkbox's own promise
that checking it "resets this".
Observed on #6326: once its true last activity fell behind the 60-day
window, and only the checkbox (never a new commit or comment) was used
to confirm it, the label thrashed on and off on a roughly 1-2 day loop.
Now a checked keepalive checkbox counts via the comment's updated_at
(when it was toggled), same as any other real activity signal.
* ci: replace actions/stale with bot-aware mark-stale script
actions/stale uses updatedAt to measure inactivity, so any bot event
(e.g. the /remove-reviewer acknowledgment comment) resets the stale
countdown even when there has been no meaningful human activity for
months. PR #6332 was last touched by a human on 2026-04-02 but was
not flagged because a reviewer-removal on 2026-06-11 refreshed the
timestamp.
Replace the actions/stale step with a custom mark-stale.js script
(same pattern as alert-stale.js) that only counts non-bot comments,
non-bot review submissions, and commits as meaningful activity. The
script also removes the stale label if such activity occurs after the
label was applied.
* ci: fix draft-stale keepalive for external contributors
Two bugs with the keepalive checkbox on draft-stale PRs:
1. External contributors (fork authors) lack write access to edit the
bot's comment, so clicking the checkbox silently fails for them.
Fix: also treat a new non-bot comment posted after the keepalive
comment as a sufficient keepalive signal.
2. The stale label could take up to 24 hours to be removed (daily cron
only). Fix: add an issue_comment.created trigger so draft-pr-policy
fires immediately when someone comments on a stale draft PR.
mark-stale and alert-stale are guarded to only run on
schedule/workflow_dispatch, not on every comment.
Also fix lastRealActivityAt to exclude bot comments (matching
mark-stale.js), so the keepalive and "Thanks for confirming" bot
comments don't count as real activity when measuring staleness.
pr.updated_at is bumped by metadata-only changes (reviewer
requested/removed, labels, milestone, assignee), letting an
abandoned draft dodge the staleness check indefinitely. Use the
latest commit/comment/review/review-comment timestamp instead.
* Add stale PR/issue policy with assignee alerts instead of auto-close
Ready PRs/issues use actions/stale to label inactivity (30/60 days).
Draft PRs get a longer 90-day window and only reset on an explicit
"still working on this" comment, since pushes/CI activity alone
shouldn't make an abandoned draft look fresh. Nothing is auto-closed:
once a staleness label has persisted past its alert threshold, a
custom script pings the assignee (falling back to requested
reviewers, then the author) to decide whether to keep it open or
close it.
* Scope stale policy to PRs only, not issues
Issue staleness is disabled (days-before-issue-stale: -1) and the
alert script now skips any non-PR item defensively, since this
workflow is meant to address PRs sitting unmerged/unreviewed, not
issue triage.
* Draft stale window 60 days (was 90); drop dead pull_request branch
alert-stale.js's pickAlertTargets is now only ever called with PR
items (filtered upstream in runAlertStale), so the pull_request
check around the requested-reviewers lookup was dead code.
* Set persist-credentials: false on checkout steps
Fixes two zizmor notes: these checkouts only need to read local
script files for github-script's require(), so there's no reason
to persist the GITHUB_TOKEN in git config afterward.
* Use a keep-alive checkbox instead of a magic comment phrase for drafts
Checking a box in the bot's own stale-notice comment is more
discoverable than requiring an exact phrase, and the live checkbox
state can be read straight off that comment's current body on each
run instead of scanning new comments for a regex match.
---------
Co-authored-by: H. Joe Lee <hyoklee@hdfgroup.org>
Scot Breitenfeld
