google-gemini / google-gemini/gemini-cli
unassign-inactive-assignees treats any open PR as progress, so stale assignments never expire
- Dominant language
- TypeScript
- Stars
- 107k
- Forks
- 14.6k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 45
Description
### 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:
```js
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:
| Issue | Assignee | Holding PR | PR last updated |
|---|---|---|---|
| #22784 | manas-raj999 | #25378 | 2026-06-02 |
| #22589 | TravisHaa | #22590 | 2026-06-02 |
| #21805 | ujjwalv01 | #27406 | 2026-06-02 |
| #18087 | KoushikAD1234 | #27415 | 2026-06-02 |
| #21691 | ProthamD | #27463 | 2026-06-09 |
| #22274 | anishs1207 | #27588 | 2026-06-02 |
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:
```js
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:
1. 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.
2. 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.
3. 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.
Contributor guide
Research direction
Read .github/workflows/unassign-inactive-assignees.yml, starting with isReady and the pulls.get call that examines linked PRs. Confirm the chosen behavior for stale PRs and fork-owned PRs, then verify that inactive assignments expire while the existing privilege exemptions remain unchanged.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, typescript
- Domain
- ci-cd, devops
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100