Require an open pull request before a second issue assignment #104

Overview

A contributor with nothing assigned can take two issues at once and leave both untouched. The limit
counts slots, not progress. Issues are tagged against the team's capacity to review them, so an
assigned issue with no pull request holds a slot that was released deliberately.

Make the second slot conditional. A contributor holding one issue gets another only when that issue
already has an open pull request.

Complexity: Medium
Target branch: main

Context

The two issue limit already exists. scripts/contributor-issue-comment.js:176 declines a /assign
when totalSlots >= MAX_ASSIGNED_ISSUES, counting open assigned issues across COMMUNITY_REPOS
plus issues dropped inside the seven day cooldown. The decline posts a comment through
sendAssignReplyAndNotify and notifies Slack.

This change extends that check. It adds no automation, no registry entry, and no second comment.

The Change

Add a progress gate to the existing limit check, in this order:

An issue counts as having an open pull request when one of the contributor's own open pull requests
links it with a closing keyword. A draft counts, because work has started. A closed pull request does
not count, because nothing is in flight.

Extend formatAssignAtLimitMessage rather than adding a message. It already lists the contributor's
current assignments. It needs to name the issue that is waiting for a pull request, and say that
unassigning it starts the seven day cooldown.

The gate applies to /assign only. A maintainer can still assign by hand, so exceptions stay
possible case by case.

Notes for the implementer

getPullRequests in scripts/utils.js already fetches a contributor's open pull requests across the
community repos. getLinkedIssues reads the closing links, but it takes the repo from
context.repo, so it needs the owner and repo passed in before it can check a pull request in
another repository.

Out of Scope

• Changing MAX_ASSIGNED_ISSUES or ASSIGN_COOLDOWN_DAYS.
• Assignment by a maintainer.
• Any new comment, workflow, or automation.

Acceptance Criteria

• A contributor with no assigned issue is assigned as today.
• A contributor with one assigned issue that has an open pull request is assigned.
• A contributor with one assigned issue and no open pull request is declined.
• A draft pull request counts as an open one.
• A closed pull request does not count.
• A pull request that links the issue without a closing keyword does not count.
• A contributor with two assigned issues is declined, as today.
• The decline names the issue waiting for a pull request, and says that unassigning starts the
  cooldown.
• The existing cooldown behaviour is unchanged.
• Tests cover each row of the table.

Testing

Test in test-actions. See
testing the automations.
The cases need an account outside the organization.

1. Comment /assign on a good first issue with nothing assigned. Expect assignment.
2. Comment /assign on a second issue. Expect a decline naming the first issue.
3. Open a pull request that closes the first issue, then comment /assign again. Expect assignment.
4. Close that pull request, then try a third issue. Expect a decline.

References

• Act on the issue a community pull request closes #103 adds getLinkedIssues, and asks a contributor to link their issue when nothing is linked.
  This gate depends on that link being there.

AI usage

I used Claude Code to check what the /assign flow already enforces and to draft this issue. I
decided the rule and the reading of what counts as progress.