Handling an External Contributor Pull Request

Overview

This playbook guides SDK maintainers through triaging and reviewing pull requests from external contributors. It covers timely triage, linked issue requirements, CI checks, saved replies for common patterns, and review processes for viable PRs. By following these steps, external contributors receive respectful, timely feedback that respects everyone's time.

Related resources:

• Review and CI Standards — review SLAs and feedback conventions
• Code Submission Standards — PR description requirements
• Saved Replies — GitHub saved replies for common scenarios
• Reviewing a PR — standard review process
• Reviewing AI-Generated Code — AI-specific checks

Steps

1. Triage within 2 business days

(Review SLAs). Every external PR REQUIRES a timely, substantive response.

2. Check for a linked issue

If the PR is non-trivial and has no linked issue, use the "Open an issue first" saved reply and close the PR.

3. Check CI status

If checks are failing, comment specifically on what's broken and give the contributor a chance to fix it.

4. Check for speculative refactors

If the PR is a style-only change or refactor with no linked issue or problem statement, use the "Let's discuss the approach first" saved reply and close the PR.

5. If the PR is viable

Review it using the standard process (Reviewing a PR). If it appears AI-generated, also apply AI-specific checks.

6. When requesting changes

You MUST be specific, use LOGAF prefixes (Review feedback conventions), and explain why — so the contributor (or their AI tool) can address the feedback effectively.

7. Closing fast is kind

A 30-second close with a clear, respectful reason is better than a PR that sits open for weeks with no response. That respects everyone's time.

Referenced Standards

• Review SLAs — timely response requirements
• Review feedback conventions — LOGAF scale for feedback
• PR description quality — linked issue requirement