Review workflow should surface same-issue PRs and reuse reviewers for non-member PRs

[vkodithala]

Summary

When the review-pull-request workflow reviews a non-member PR, it should detect other PRs associated with the same issue and use that context to keep reviewer assignment consistent.

This should be limited to non-member PRs. That is likely the main surface where multiple external contributors may independently submit PRs solving the same issue, and it avoids expanding reviewer-assignment behavior for normal member/collaborator PRs.

Current behavior

From the current review workflow:

• Explicit review routing recognizes /oz-review and @oz-agent /review on PR comments/review comments.
• ReviewWorkflow.build_dispatch gathers review context through core/workflows/review_pr.py:gather_review_context.
• gather_review_context resolves a linked issue number via existing PR association helpers and uses it for spec context.
• For non-member PRs, the workflow loads .github/STAKEHOLDERS and asks the agent to recommend exactly one reviewer after an Oz APPROVE verdict.
• apply_review_result validates the recommendation against STAKEHOLDERS or falls back to deterministic path-based stakeholder selection.

What is missing:

• The review context does not enumerate other open PRs associated with the same issue.
• The agent review prompt does not surface related/sibling PRs.
• Reviewer assignment does not currently prefer a reviewer already reviewing another PR for the same issue.

Problem

For non-member PRs, we can get multiple PRs that solve the same issue. If separate reviewers are assigned independently by changed-path ownership, two different maintainers may review competing approaches without enough context. Ideally, one reviewer should review all PRs for the same issue and decide which approach to accept or how to reconcile them.

Desired behavior

For non-member PRs only:

1. When review-pull-request gathers context, resolve the PR's associated same-repo issue using the existing issue-association machinery.
2. If a linked issue is found, discover other PRs in the same repo associated with that issue, excluding the current PR.
3. Surface those related PRs to the review run as control-plane-provided context, e.g. an attachment such as related_prs.md, rather than asking the agent to call GitHub.
4. Prefer reviewer reuse when applying the review result:
   • If an open sibling PR for the same issue already has a requested human reviewer, request that reviewer on the current PR.
   • Otherwise, if a human has already reviewed a sibling PR for the same issue, prefer that reviewer.
   • Otherwise, fall back to the existing STAKEHOLDERS-based reviewer selection.
5. If there are multiple plausible existing reviewers and no clear deterministic winner, do not guess silently. Surface the ambiguity in the progress/review context and fall back conservatively.

Non-goals

• Do not apply this reviewer-reuse behavior to member/collaborator PRs for now.
• Do not ask the review agent to fetch GitHub data directly. The review prompt currently tells agents not to run gh or make ad-hoc GitHub API calls, so related PR context should be gathered by the workflow/control plane.
• Do not change the core review.json schema unless strictly necessary.
• Do not replace STAKEHOLDERS-based selection; this should be a higher-priority input for non-member PRs when same-issue reviewer context exists.

Implementation notes

Likely touch points:

• oz/helpers.py
  • Reuse or extend resolve_pr_association / resolve_issue_number_for_pr.
  • Add a helper to discover related PRs for a given same-repo issue.
• core/workflows/review_pr.py
  • Extend ReviewContext with linked issue and related PR context.
  • Add an attachment or prompt section for related PRs.
  • Update reviewer resolution in apply_review_result so related-PR reviewer reuse is preferred before STAKEHOLDERS fallback for non-member approved PRs.
• tests
  • Add routing/context tests for related PR discovery once issue association resolves.
  • Add reviewer selection tests covering: requested reviewer reuse, prior human reviewer reuse, ambiguous reviewers, fallback to STAKEHOLDERS, and exclusion of the PR author/bots.

Acceptance criteria

• Non-member PR review runs include related same-issue PR context when sibling PRs exist.
• Non-member PRs reviewed by Oz prefer a reviewer already associated with a sibling PR for the same issue.
• Existing STAKEHOLDERS fallback behavior remains unchanged when no related reviewer signal exists.
• Member/collaborator PRs keep their existing no-reviewer-request behavior.
• The review agent is not required to call GitHub to discover sibling PRs.

[oz-for-oss]

@vkodithala

Here's what I found while triaging this issue:

The report matches the current workflow behavior: related same-issue PRs are not gathered, and reviewer reuse is not currently considered before the STAKEHOLDERS fallback. No reporter follow-up is needed for initial triage.

Maintainer details

I concluded that the review workflow currently lacks same-issue sibling PR context and reviewer reuse for non-member PRs, so this is a reproducible workflow enhancement..

Triage summary

This is a reproducible workflow enhancement. The current review workflow resolves an associated issue for spec lookup, but it does not enumerate sibling PRs tied to that issue, pass related PR context into the review run, or prioritize existing sibling PR reviewer signals before the STAKEHOLDERS fallback.

Likely implementation areas:

• oz/helpers.py: extend the existing PR/issue association helpers with same-repo related PR discovery.
• core/workflows/review_pr.py: add related PR data to ReviewContext, include it in the dispatched review context/prompt or attachment, and prefer deterministic related-PR reviewer reuse for approved non-member PRs before STAKEHOLDERS fallback.
• core/workflows/__init__.py: ensure the gathered context is preserved in the workflow payload subset.
• tests/test_review_pr_reviewer_sampling.py and related workflow tests: cover requested-reviewer reuse, prior-human-review reuse, ambiguity fallback, bot/author exclusion, and unchanged member/collaborator behavior.

Duplicate search checked open repository issues plus recently closed issues and did not find enough matching duplicate candidates to mark this as a duplicate.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz