What happened?
.github/workflows/unassign-inactive-assignees.yml unassigns a help wanted assignee after 7 days if they have no qualifying linked PR. The qualifying check is:
const isReady = (pr.state === 'open' && !pr.draft) ||
(pr.state === 'closed' && pr.merged_at !== null);
It looks at state, draft and merged. It never looks at pr.updated_at. So one non-draft PR keeps an assignment alive forever, no matter how long that PR has been dead.
That is what is happening to the label right now. Every one of these assignments is being held open by a PR that has not been touched in two to three months:
There are 29 open help wanted issues. 28 have an assignee. The only unassigned one is #4191, the public roadmap tracker. For a label whose purpose is to route work to outside contributors, there is currently nothing on it to pick up.
Second gap in the same check. The PR is fetched from whichever repo the cross-reference came from:
const { data: pr } = await github.rest.pulls.get({
owner: prOwner, repo: prRepo, pull_number: prNumber,
});
There is no check that prOwner/prRepo is this repository. A non-draft PR opened inside someone's own fork, referencing an upstream issue, satisfies the check. #22274 already has a HaleTom/gemini-cli#1 cross-reference sitting in its timeline. That one is a draft so it does not fire, but nothing stops the non-draft version.
What did you expect to happen?
An assignment held by a PR that has been silent for months should expire, so the issue returns to the pool.
Suggestions, and I am happy to send a PR for whichever direction you prefer:
- Add a freshness requirement to
isReady, for example the PR must have been updated within the last 30 days. Keep the existing 7 day rule for the case where no PR exists at all.
- Before unassigning on the stale-PR path, have the workflow post one comment on the issue asking the assignee to confirm they are still on it, and only unassign if there is no reply after another 7 days. That avoids pulling an issue out from under someone who is mid-rebase.
- Require the linked PR to live in this repository, not in a fork's own repo.
Note on exemptions: the workflow already skips maintainers, org members and anyone with triage or above via isPrivilegedUser, and that logic does not need to change. This only affects outside contributors, which is the group the grace period was written for in the first place.
Client information
Not applicable. This is a repository automation issue, not a CLI issue.
Anything else we need to know?
Numbers above were read from the API on 2026-08-13 and will drift.
What happened?
.github/workflows/unassign-inactive-assignees.ymlunassigns ahelp wantedassignee after 7 days if they have no qualifying linked PR. The qualifying check is:It looks at state, draft and merged. It never looks at
pr.updated_at. So one non-draft PR keeps an assignment alive forever, no matter how long that PR has been dead.That is what is happening to the label right now. Every one of these assignments is being held open by a PR that has not been touched in two to three months:
There are 29 open
help wantedissues. 28 have an assignee. The only unassigned one is #4191, the public roadmap tracker. For a label whose purpose is to route work to outside contributors, there is currently nothing on it to pick up.Second gap in the same check. The PR is fetched from whichever repo the cross-reference came from:
There is no check that
prOwner/prRepois this repository. A non-draft PR opened inside someone's own fork, referencing an upstream issue, satisfies the check. #22274 already has aHaleTom/gemini-cli#1cross-reference sitting in its timeline. That one is a draft so it does not fire, but nothing stops the non-draft version.What did you expect to happen?
An assignment held by a PR that has been silent for months should expire, so the issue returns to the pool.
Suggestions, and I am happy to send a PR for whichever direction you prefer:
isReady, for example the PR must have been updated within the last 30 days. Keep the existing 7 day rule for the case where no PR exists at all.Note on exemptions: the workflow already skips maintainers, org members and anyone with
triageor above viaisPrivilegedUser, and that logic does not need to change. This only affects outside contributors, which is the group the grace period was written for in the first place.Client information
Not applicable. This is a repository automation issue, not a CLI issue.
Anything else we need to know?
Numbers above were read from the API on 2026-08-13 and will drift.