Hi all, I want to flag a process problem we recently caught and the fix we've put in place, so the community is aware and can weigh in.
What happened A contributor picked up an issue (#8149), followed the correct steps, and opened a valid PR (#8267) with a fix. Separately, an AI agent later opened its own PR (#8339) for the same issue. The agent's PR was reviewed and merged first, which meant the original contributor received no credit for work they had done correctly and submitted earlier. It's a failure mode common across open-source projects, and it's worth fixing properly rather than treating it as a one-off. How we identified it The duplication surfaced during routine PR review, when the same issue number appeared on two independent PRs. The root cause was that GitHub can leave an issue looking "unassigned" even when there is an open, linked PR, so there was no reliable, at-a-glance indicator that the issue was taken. How it will be handled going forward Two PRs have been opened to make this much less likely: - #8675 (docs / AGENTS.md): Defines when an issue counts as "taken" (someone else assigned, or someone else has an open linked PR), and requires claiming an issue with /take before starting. It also adds a mandatory re-check of every issue a diff closes immediately before opening the PR, so it drops already-claimed issues from the changeset. This covers both human contributors and AI agents. - #8678 (CI / GitHub Actions): Adds an automated check (.github/workflows/pr-assignment.yml plus a tested issue-claims.js decision module, 24 passing unit tests) that inspects every issue a PR references. When a PR would close an issue already claimed by someone else by assignee or by an existing open PR, the workflow posts a comment naming the original claimant and their PR, and removes it once the conflict clears. Just as importantly, the merge-time credit step now preserves the original claimant instead of unassigning them. A dry run flagged 2 real conflicts across 218 open PRs, so the detection works on live data. Together, these give us a visible, automated signal at the two moments it matters most: before someone starts coding, and before a PR is merged. Going forward, committers and contributors alike will use /take to claim issues, and rely on the CI check as a backstop. Feedback on the two PRs is welcome before they merge. Best, Matthew Ball
