Preventing duplicate work and lost credit on claimed issues

[Matthew Ball <mg...@uci.edu>]

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

Re: Preventing duplicate work and lost credit on claimed issues

[Chen Li <ch...@apache.org>]

Matthew and Team,

Thanks a lot for identifying the problem, replying to the contributor to
acknowledge our mistake, and fixing the problem quickly with the PRs.  We
want to streamline the development process, welcome contributors to the
community, and acknowledge their effort by giving them the proper credits.  We
will continuously improve our practice to develop the system.

Cheers,

Chen Li

On Sun, Sep 27, 2026 at 2:55 PM Matthew Ball <mg...@uci.edu> wrote:

> 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
>