[WIP] Measure inactivity as unanswered feedback to the assignee

Start with scripts/unassign-inactive-issues.js and scripts/constants.js, then read scripts/contributor-pr-reply.js and the automation testing guide linked in the issue. Run the workflow manually in test-actions and use the six scenarios listed under Testing. Done means unanswered feedback drives per-assignee inactivity, review waits and the bounded comment grace behave as specified, and removal closes only the assignee’s eligible open pull requests.

Overview

The weekly sweep unassigns a contributor after 30 days of inactivity. It measures the issue's
activity, not the assignee's. Anyone who comments resets the clock, and the bot's own replies to
those comments reset it again. A stalled issue therefore holds its assignee for as long as other
people keep asking for it.

Measure inactivity as feedback that the assignee left unanswered.

Context

On learningequality/kolibri#14261 the assignee last commented on the issue on 2026-07-05. A
maintainer removed them by hand on 2026-10-23. At that moment issue.updated_at was 2026-10-12,
that is 11 days, so the sweep would never have fired. Four other people had asked for the issue
in the meantime, and the bot replied to each one, which reset the clock again.

The linked pull request tells the real story:

Date	Event
2026-08-25	A maintainer requested changes
2026-08-29	The assignee replied and pushed, that is 4 days later
2026-09-01	The assignee's last commit
2026-09-03	A maintainer commented
2026-09-14	rtibblesbot reviewed, and a maintainer commented again
2026-10-04	The assignee replied, that is 31 days after the 2026-09-03 feedback
2026-10-23	A maintainer removed them by hand

Feedback sat unanswered from 2026-09-03. A 14-day limit on unanswered feedback fires on
2026-09-17, five weeks before the manual removal. The 2026-09-01 to 2026-09-03 window, when the
assignee was waiting on review, stays safe.

scripts/unassign-inactive-issues.js reads the issue instead:

const lastActivity = new Date(issue.updated_at);
if (now - lastActivity <= inactivityThresholdMs) { continue; }

The linked pull request guard compounds it. checkLinkedPRs skips the issue when any open linked
pull request exists, however old that pull request is.

The Change

Define pending feedback. It is the most recent comment, review, or review comment on the
issue or on a linked open pull request, written by an organization member, a site admin, or
rtibblesbot. A comment from another contributor starts no clock, because it is not feedback.

learning-equality-bot[bot] is not feedback either. Its own messages, including the reminder in
#129, must never start a clock or the automations fight each other.

Run a clock, and pause it only when the assignee waits on someone else. The clock runs from
the latest of the assignment date, the last unanswered feedback, the assignee's last commit, and
the date a linked pull request closed. An assignee is inactive when the clock passes
INACTIVITY_DAYS.

Pause while waiting on review. An open linked pull request whose last commit or reply from
the assignee is newer than the last feedback on it means the ball is with the reviewer. The clock
pauses until feedback lands. Waiting on review costs the assignee nothing, however long it takes.

Pause for a bounded grace after the assignee comments. The assignee's first comment after
feedback lands pauses the clock for COMMENT_GRACE_DAYS. Those days do not count toward the
limit. A reply from a maintainer or the bot inside the window ends the pause, and the clock
restarts from that reply. With no reply, the clock resumes where it stopped.

One grace window applies per feedback item, so a second comment buys nothing. A comment never
resets the clock. This is what stops a contributor from holding an issue with a sentence every
13 days. The longest a single feedback item runs is INACTIVITY_DAYS plus
COMMENT_GRACE_DAYS, that is 21 days.

Add INACTIVITY_DAYS to scripts/constants.js, set to 14, down from the current 30, and
COMMENT_GRACE_DAYS, set to 7. The weekly cadence is unchanged.

Drop the open pull request guard. An open linked pull request no longer protects an
assignment on its own. Feedback on that pull request is what drives the clock.

Close the assignee's open pull requests on removal. Comment on each one with the reason and
with the note that a maintainer can reopen it, then close it, following the shape in
scripts/contributor-pr-reply.js. Only pull requests linked to the issue and authored by the
removed assignee are closed. A merged pull request and a pull request by anyone else are left
alone. A close that fails warns and the sweep carries on, because one pull request must not stop
the rest of the run. The Slack output names the closed pull requests next to the unassignments.

BOT_MESSAGE_PULL_REQUEST_CLOSED states a different reason, that is the issue being assigned to
someone else, so this needs its own message constant.

Export the measure. The reminder automation reads the same number, so the helper that returns
the pending feedback and its age is exported rather than private.

Measure each assignee separately. An issue with two assignees can have one who answered and
one who did not, and only the second one goes.

Out of Scope

• Changing the weekly cadence.
• Changing which assignees are exempt. Organization members and site admins stay exempt.
• The cooldown on re-assignment, which is #127.
• The midweek reminder, which is its own issue.

Acceptance Criteria

• A comment from anyone other than a maintainer, a site admin or rtibblesbot starts no
  clock.
• An assignee waiting on review is never unassigned, however long the wait.
• Feedback answered by a commit pauses the clock.
• Feedback unanswered for 14 days leads to an unassignment.
• One comment from the assignee delays the unassignment by 7 days, and no more.
• A second comment on the same feedback item delays nothing.
• A reply from a maintainer inside the grace window restarts the clock from that reply.
• A contributor assigned within 14 days is never unassigned, even with no comment.
• A contributor assigned more than 21 days ago who has only commented is unassigned.
• A stale open linked pull request does not protect the assignment.
• An unassignment closes the assignee's open linked pull requests, and each one carries a
  comment with the reason.
• A merged pull request, and a pull request by another author, are left open.
• A close that fails does not stop the rest of the run.
• On an issue with two assignees, only the one who left feedback unanswered is unassigned.
• Organization members and site admins are never unassigned.
• The pending feedback helper is exported.

Testing

Test in test-actions. See
testing the automations.
Dispatch the workflow by hand rather than waiting for the cron.

1. Assign a contributor account to an issue, then comment from the maintainer account. Dispatch
   the sweep. Expect no unassignment, because the feedback is recent.
2. Comment from a third account instead. Dispatch the sweep. Expect no unassignment, because that
   comment is not feedback.
3. Open a linked pull request from the contributor account and leave it without review. Dispatch
   the sweep. Expect no unassignment, because nothing is pending.
4. Review that pull request from the maintainer account and leave the review unanswered past 14
   days. Dispatch the sweep. Expect an unassignment, and expect the pull request to be closed
   with a comment.
5. Answer the review with a commit instead. Dispatch the sweep. Expect no unassignment.
6. Answer the review with a comment only, and dispatch the sweep on day 15 and again on day 22.
   Expect no unassignment on day 15 and an unassignment on day 22.

References

The real case is learningequality/kolibri#14261 and its linked pull request. The re-assignment
cooldown that depends on this is #127.

AI usage

I used Claude Code to read the sweep, to trace the comment, commit and review history of
kolibri#14261 and its linked pull request, and to confirm that issue.updated_at was 11 days old
when the assignee had left feedback unanswered for 50. I decided that inactivity means unanswered
feedback, that waiting on review is not inactivity, that a comment buys one bounded grace window
rather than resetting the clock, and that a removal closes the assignee's open pull requests.