Docs: revise PR and issue submission guides (#10617)

* Docs: revise PR submission guide

* Docs: revise issue submission guide
This commit is contained in:
Tak Hoffman
2026-02-06 13:29:11 -06:00
committed by GitHub
parent 4216449405
commit e3d3893d5d
2 changed files with 317 additions and 217 deletions

View File

@@ -3,283 +3,396 @@ summary: "How to submit a high signal PR"
title: "Submitting a PR" title: "Submitting a PR"
--- ---
# Submitting a PR Good PRs are easy to review: reviewers should quickly know the intent, verify behavior, and land changes safely. This guide covers concise, high-signal submissions for human and LLM review.
Good PRs make it easy for reviewers to understand intent, verify behavior, and land changes safely. This guide focuses on high-signal, low-noise submissions that work well with both human review and LLM-assisted review.
## What makes a good PR ## What makes a good PR
- [ ] Clear intent: explain the problem, why it matters, and what the change does. - [ ] Explain the problem, why it matters, and the change.
- [ ] Tight scope: keep changes focused and avoid drive-by refactors. - [ ] Keep changes focused. Avoid broad refactors.
- [ ] Behavior summary: call out user-visible changes, config changes, and defaults. - [ ] Summarize user-visible/config/default changes.
- [ ] Tests: list what ran, what was skipped, and why. - [ ] List test coverage, skips, and reasons.
- [ ] Evidence: include logs, screenshots, or short recordings for UI or workflows. - [ ] Add evidence: logs, screenshots, or recordings (UI/UX).
- [ ] Code word: include “lobster-biscuit” somewhere in the PR description to confirm you read this guide. - [ ] Code word: put “lobster-biscuit” in the PR description if you read this guide.
- [ ] Baseline checks: run the relevant `pnpm` commands for this repo and fix failures before opening the PR. - [ ] Run/fix relevant `pnpm` commands before creating PR.
- [ ] Due diligence: search the codebase for existing functionality and check GitHub for related issues or prior fixes. - [ ] Search codebase and GitHub for related functionality/issues/fixes.
- [ ] Grounded in reality: claims should be backed by evidence, reproduction, or direct observation. - [ ] Base claims on evidence or observation.
- [ ] Title guidance: use a verb + scope + outcome (for example `Docs: add PR and issue templates`). - [ ] Good title: verb + scope + outcome (e.g., `Docs: add PR and issue templates`).
Guideline: concision > grammar. Be terse if it makes review faster. Be concise; concise review > grammar. Omit any non-applicable sections.
Baseline validation commands (run as appropriate for the change, and fix failures before submitting): ### Baseline validation commands (run/fix failures for your change):
- `pnpm lint` - `pnpm lint`
- `pnpm check` - `pnpm check`
- `pnpm build` - `pnpm build`
- `pnpm test` - `pnpm test`
- If you touch protocol code: `pnpm protocol:check` - Protocol changes: `pnpm protocol:check`
## Progressive disclosure ## Progressive disclosure
Use a short top section, then deeper details as needed. - Top: summary/intent
- Next: changes/risks
- Next: test/verification
- Last: implementation/evidence
1. Summary and intent ## Common PR types: specifics
2. Behavior changes and risks
3. Tests and verification
4. Implementation details and evidence
This keeps review fast while preserving deep context for anyone who needs it. - [ ] Fix: Add repro, root cause, verification.
- [ ] Feature: Add use cases, behavior/demos/screenshots (UI).
## Common PR types and expectations - [ ] Refactor: State "no behavior change", list what moved/simplified.
- [ ] Chore: State why (e.g., build time, CI, dependencies).
- [ ] Fix: include clear repro, root cause summary, and verification steps. - [ ] Docs: Before/after context, link updated page, run `pnpm format`.
- [ ] Feature: include use cases, behavior changes, and screenshots or demos when UI is involved. - [ ] Test: What gap is covered; how it prevents regressions.
- [ ] Refactor: explicitly state “no behavior change” and list what moved or was simplified. - [ ] Perf: Add before/after metrics, and how measured.
- [ ] Chore/Maintenance: note why it matters (build time, CI stability, dependency hygiene). - [ ] UX/UI: Screenshots/video, note accessibility impact.
- [ ] Docs: include before/after context and link to the updated page. Run `pnpm format`. - [ ] Infra/Build: Environments/validation.
- [ ] Test: explain the gap it covers and how it prevents regressions. - [ ] Security: Summarize risk, repro, verification, no sensitive data. Grounded claims only.
- [ ] Perf: include baseline and after metrics, plus how they were measured.
- [ ] UX/UI: include screenshots or short recordings and any accessibility impact.
- [ ] Infra/Build: call out affected environments and how to validate.
- [ ] Security: include threat or risk summary, repro steps, and verification plan. Avoid sensitive data in public logs.
- [ ] Security: keep reports grounded in reality; avoid speculative claims.
## Checklist ## Checklist
- [ ] Problem and intent are clear - [ ] Clear problem/intent
- [ ] Scope is focused - [ ] Focused scope
- [ ] Behavior changes are listed - [ ] List behavior changes
- [ ] Tests are listed with results - [ ] List and result of tests
- [ ] Evidence is attached when needed - [ ] Manual test steps (when applicable)
- [ ] No secrets or private data - [ ] No secrets/private data
- [ ] Grounded in reality: no guesswork or invented context. - [ ] Evidence-based
## Template ## General PR Template
```md ```md
## Summary #### Summary
## Behavior Changes #### Behavior Changes
## Codebase and GitHub Search #### Codebase and GitHub Search
## Tests #### Tests
## Evidence #### Manual Testing (omit if N/A)
## Sign-Off ### Prerequisites
-
### Steps
1.
2.
#### Evidence (omit if N/A)
**Sign-Off**
- Models used: - Models used:
- Submitter effort summary (self-reported, subjective): - Submitter effort (self-reported):
- Agent notes (optional; brief; cite evidence): - Agent notes (optional, cite evidence):
``` ```
## Templates by PR type ## PR Type templates (replace with your type)
### Fix ### Fix
```md ```md
## Summary #### Summary
## Repro Steps #### Repro Steps
## Root Cause #### Root Cause
## Behavior Changes #### Behavior Changes
## Tests #### Tests
## Evidence #### Manual Testing (omit if N/A)
## Sign-Off ### Prerequisites
-
### Steps
1.
2.
#### Evidence (omit if N/A)
**Sign-Off**
- Models used: - Models used:
- Submitter effort summary (self-reported, subjective): - Submitter effort:
- Agent notes (optional; brief; cite evidence): - Agent notes:
``` ```
### Feature ### Feature
```md ```md
## Summary #### Summary
## Use Cases #### Use Cases
## Behavior Changes #### Behavior Changes
## Existing Functionality Check #### Existing Functionality Check
- [ ] I searched the codebase for existing functionality before implementing this. - [ ] I searched the codebase for existing functionality.
Searches performed (1-3 bullets):
-
-
Searches performed (1-3 bullets, one sentence each): #### Tests
#### Manual Testing (omit if N/A)
### Prerequisites
-
- -
## Tests ### Steps
## Evidence 1.
2.
## Sign-Off #### Evidence (omit if N/A)
**Sign-Off**
- Models used: - Models used:
- Submitter effort summary (self-reported, subjective): - Submitter effort:
- Agent notes (optional; brief; cite evidence): - Agent notes:
``` ```
### Refactor ### Refactor
```md ```md
## Summary #### Summary
## Scope #### Scope
## No Behavior Change Statement #### No Behavior Change Statement
## Tests #### Tests
## Sign-Off #### Manual Testing (omit if N/A)
### Prerequisites
-
### Steps
1.
2.
#### Evidence (omit if N/A)
**Sign-Off**
- Models used: - Models used:
- Submitter effort summary (self-reported, subjective): - Submitter effort:
- Agent notes (optional; brief; cite evidence): - Agent notes:
``` ```
### Chore/Maintenance ### Chore/Maintenance
```md ```md
## Summary #### Summary
## Why This Matters #### Why This Matters
## Tests #### Tests
## Sign-Off #### Manual Testing (omit if N/A)
### Prerequisites
-
### Steps
1.
2.
#### Evidence (omit if N/A)
**Sign-Off**
- Models used: - Models used:
- Submitter effort summary (self-reported, subjective): - Submitter effort:
- Agent notes (optional; brief; cite evidence): - Agent notes:
``` ```
### Docs ### Docs
```md ```md
## Summary #### Summary
## Pages Updated #### Pages Updated
## Screenshots or Before/After #### Before/After
## Formatting #### Formatting
pnpm format pnpm format
## Sign-Off #### Evidence (omit if N/A)
**Sign-Off**
- Models used: - Models used:
- Submitter effort summary (self-reported, subjective): - Submitter effort:
- Agent notes (optional; brief; cite evidence): - Agent notes:
``` ```
### Test ### Test
```md ```md
## Summary #### Summary
## Gap Covered #### Gap Covered
## Tests #### Tests
## Sign-Off #### Manual Testing (omit if N/A)
### Prerequisites
-
### Steps
1.
2.
#### Evidence (omit if N/A)
**Sign-Off**
- Models used: - Models used:
- Submitter effort summary (self-reported, subjective): - Submitter effort:
- Agent notes (optional; brief; cite evidence): - Agent notes:
``` ```
### Perf ### Perf
```md ```md
## Summary #### Summary
## Baseline #### Baseline
## After #### After
## Measurement Method #### Measurement Method
## Tests #### Tests
## Sign-Off #### Manual Testing (omit if N/A)
### Prerequisites
-
### Steps
1.
2.
#### Evidence (omit if N/A)
**Sign-Off**
- Models used: - Models used:
- Submitter effort summary (self-reported, subjective): - Submitter effort:
- Agent notes (optional; brief; cite evidence): - Agent notes:
``` ```
### UX/UI ### UX/UI
```md ```md
## Summary #### Summary
## Screenshots or Video #### Screenshots or Video
## Accessibility Impact #### Accessibility Impact
## Tests #### Tests
## Sign-Off #### Manual Testing
### Prerequisites
-
### Steps
1.
2. **Sign-Off**
- Models used: - Models used:
- Submitter effort summary (self-reported, subjective): - Submitter effort:
- Agent notes (optional; brief; cite evidence): - Agent notes:
``` ```
### Infra/Build ### Infra/Build
```md ```md
## Summary #### Summary
## Environments Affected #### Environments Affected
## Validation Steps #### Validation Steps
## Sign-Off #### Manual Testing (omit if N/A)
### Prerequisites
-
### Steps
1.
2.
#### Evidence (omit if N/A)
**Sign-Off**
- Models used: - Models used:
- Submitter effort summary (self-reported, subjective): - Submitter effort:
- Agent notes (optional; brief; cite evidence): - Agent notes:
``` ```
### Security ### Security
```md ```md
## Summary #### Summary
## Risk Summary #### Risk Summary
## Repro Steps #### Repro Steps
## Mitigation or Fix #### Mitigation or Fix
## Verification #### Verification
## Tests #### Tests
## Sign-Off #### Manual Testing (omit if N/A)
### Prerequisites
-
### Steps
1.
2.
#### Evidence (omit if N/A)
**Sign-Off**
- Models used: - Models used:
- Submitter effort summary (self-reported, subjective): - Submitter effort:
- Agent notes (optional; brief; cite evidence): - Agent notes:
``` ```

View File

@@ -1,165 +1,152 @@
--- ---
summary: "How to file high signal issues and bug reports" summary: "Filing high-signal issues and bug reports"
title: "Submitting an Issue" title: "Submitting an Issue"
--- ---
# Submitting an Issue ## Submitting an Issue
Good issues make it easy to reproduce, diagnose, and fix problems quickly. This guide covers what to include for bugs, regressions, and feature gaps. Clear, concise issues speed up diagnosis and fixes. Include the following for bugs, regressions, or feature gaps:
## What makes a good issue ### What to include
- [ ] Clear title: include the area and the symptom. - [ ] Title: area & symptom
- [ ] Repro steps: minimal steps that consistently reproduce the issue. - [ ] Minimal repro steps
- [ ] Expected vs actual: what you thought would happen and what did. - [ ] Expected vs actual
- [ ] Impact: who is affected and how severe the problem is. - [ ] Impact & severity
- [ ] Environment: OS, runtime, versions, and relevant config. - [ ] Environment: OS, runtime, versions, config
- [ ] Evidence: logs, screenshots, or recordings (redacted; prefer non-PII data). - [ ] Evidence: redacted logs, screenshots (non-PII)
- [ ] Scope: note if it is new, regression, or long-standing. - [ ] Scope: new, regression, or longstanding
- [ ] Code word: include “lobster-biscuit” somewhere in the issue description to confirm you read this guide. - [ ] Code word: lobster-biscuit in your issue
- [ ] Due diligence: search the codebase for existing functionality and check GitHub to see if the issue is already filed or fixed. - [ ] Searched codebase & GitHub for existing issue
- [ ] I searched for existing and recently closed issues/PRs. - [ ] Confirmed not recently fixed/addressed (esp. security)
- [ ] For security reports: confirmed it has not already been fixed or addressed recently. - [ ] Claims backed by evidence or repro
- [ ] Grounded in reality: claims should be backed by evidence, reproduction, or direct observation.
Guideline: concision > grammar. Be terse if it makes review faster. Be brief. Terseness > perfect grammar.
Baseline validation commands (run as appropriate for the change, and fix failures before submitting a PR): Validation (run/fix before PR):
- `pnpm lint` - `pnpm lint`
- `pnpm check` - `pnpm check`
- `pnpm build` - `pnpm build`
- `pnpm test` - `pnpm test`
- If you touch protocol code: `pnpm protocol:check` - If protocol code: `pnpm protocol:check`
## Templates ### Templates
### Bug report #### Bug report
```md ```md
## Bug report checklist - [ ] Minimal repro
- [ ] Minimal repro steps
- [ ] Expected vs actual - [ ] Expected vs actual
- [ ] Versions and environment - [ ] Environment
- [ ] Affected channels and where it does not reproduce - [ ] Affected channels, where not seen
- [ ] Logs or screenshots - [ ] Logs/screenshots (redacted)
- [ ] Evidence is redacted and non-PII where possible - [ ] Impact/severity
- [ ] Impact and severity - [ ] Workarounds
- [ ] Any known workarounds
## Summary ### Summary
## Repro Steps ### Repro Steps
## Expected ### Expected
## Actual ### Actual
## Environment ### Environment
## Logs or Evidence ### Logs/Evidence
## Impact ### Impact
## Workarounds ### Workarounds
``` ```
### Security issue #### Security issue
```md ```md
## Summary ### Summary
## Impact ### Impact
## Affected Versions ### Versions
## Repro Steps (if safe to share) ### Repro Steps (safe to share)
## Mitigation or Workaround ### Mitigation/workaround
## Evidence (redacted) ### Evidence (redacted)
``` ```
Security note: avoid posting secrets or exploit details in public issues. If the report is sensitive, keep repro details minimal and ask for a private disclosure path. _Avoid secrets/exploit details in public. For sensitive issues, minimize detail and request private disclosure._
### Regression report #### Regression report
```md ```md
## Summary ### Summary
## Last Known Good ### Last Known Good
## First Known Bad ### First Known Bad
## Repro Steps ### Repro Steps
## Expected ### Expected
## Actual ### Actual
## Environment ### Environment
## Logs or Evidence ### Logs/Evidence
## Impact ### Impact
``` ```
### Feature request #### Feature request
```md ```md
## Summary ### Summary
## Problem ### Problem
## Proposed Solution ### Proposed Solution
## Alternatives Considered ### Alternatives
## Impact ### Impact
## Evidence or Examples ### Evidence/examples
``` ```
### Enhancement request #### Enhancement
```md ```md
## Summary ### Summary
## Current Behavior ### Current vs Desired Behavior
## Desired Behavior ### Rationale
## Why This Matters ### Alternatives
## Alternatives Considered ### Evidence/examples
## Evidence or Examples
``` ```
### Investigation request #### Investigation
```md ```md
## Summary ### Summary
## Symptoms ### Symptoms
## What Was Tried ### What Was Tried
## Environment ### Environment
## Logs or Evidence ### Logs/Evidence
## Impact ### Impact
``` ```
## If you are submitting a fix PR ### Submitting a fix PR
Creating a separate issue first is optional. If you skip it, include the relevant details in the PR description. Issue before PR is optional. Include details in PR if skipping. Keep the PR focused, note issue number, add tests or explain absence, document behavior changes/risks, include redacted logs/screenshots as proof, and run proper validation before submitting.
- Keep the PR focused on the issue.
- Include the issue number in the PR description.
- Add tests when possible, or explain why they are not feasible.
- Note any behavior changes and risks.
- Include redacted logs, screenshots, or videos that validate the fix.
- Run relevant `pnpm` validation commands and report results when appropriate.