WHY ENGLISH?
Help a reviewer understand the problem, boundaries, approach, evidence and risk of a proposed change before they enter the diff—and keep that shared map accurate through review
Writing a pull request description means explaining the problem, intended outcome, scope, approach, major changes, testing, screenshots or evidence, risks, dependencies, reviewer focus and follow-up. English matters because a pull request is not only a bundle of code; it is a proposal that asks other people to understand and judge a change.
GitHub’s current guidance says a pull request proposes merging changes from one branch into another. Its reviewer guidance says clear titles and descriptions help reviewers understand the problem, approach and result, and recommends splitting large changes into smaller pull requests that serve one purpose. GitHub’s template documentation shows that repositories can prompt contributors for issue references, proposed changes and responsible reviewers.
This guide follows a fictional pull request that adds a weekly assignment filter to a school learning platform. It does not approve or merge code, certify security, replace the diff, tests or repository template, promise compatibility or authorise sharing student data in screenshots. Every project should follow its own contribution and review rules.
Article contents
Open all chapters
- 1. State the Problem Before the Implementation
- 2. Define the Intended Outcome
- 3. Draw the Scope and Non-Scope
- 4. Summarise the Approach and Alternatives
- 5. Map the Important Changes
- 6. Call Out Changed Behaviour and Compatibility
- 7. Report Testing as Evidence
- 8. Use Screenshots and Demonstrations Safely
- 9. Surface Risks, Rollout and Recovery
- 10. Ask for Specific Review Attention
- 11. Keep the Description Current
- 12. Close With Decision and Follow-Up
ORIENTATION
What this guide covers
Current fact check
Checked on 9 November 2026, GitHub Docs defined a pull request as a proposal to merge changes from one branch into another. Its review guidance said a clear title and description help reviewers understand the problem, approach and result, and advised splitting large changes into smaller requests that serve one purpose. GitHub’s template guidance allowed repositories to request related issues, a description of proposed changes and reviewer mentions.
What this guide does not cover
This article owns drafting, updating and closing the communication loop in a pull request description. It does not own code correctness, commit-message history, issue triage, reviewer comments, merge authority, branch protection, continuous integration, security approval, release notes, deployment, production monitoring or permission to disclose private data.
Worked example
Every chapter returns to a fictional school learning-platform change that adds a weekly assignment filter, updates keyboard behaviour and includes tests without changing assignment permissions. It is fictional, low-stakes and educational; it does not report a real school, clinical decision or guaranteed outcome.
Did You Know? For pull request description, precise communication makes appraisal possible but does not perform the appraisal, remove bias or guarantee transfer.
Warm up with eduKate’s guides to explaining scientific evidence and asking better questions in class.
CHAPTER 1 OF 12
1. State the Problem Before the Implementation
Why this move matters
Explain the user or system difficulty and the evidence that makes the change worth reviewing.
Did You Know? Problem-first writing lets reviewers assess fit.
Begin with the reviewer’s decision problem
Explain the user or system difficulty and the evidence that makes the change worth reviewing. For Students with many assignments must scan a long list to find work due this week., explain the user or system problem, why this approach was chosen and what is deliberately outside the request.
Map claims to visible changes and tests
Name affected areas, test evidence, screenshots or reproducible checks so the reviewer can verify the result. Preserve this limit: A reported frustration does not prove the chosen solution is best.
Surface risk, migration and review attention
Point reviewers to high-risk files, changed defaults, data effects, accessibility concerns, rollout or follow-up rather than hiding them in a large diff.
Keep the description current through review
Update material scope changes, answer comments and record the final decision without rewriting away important history. A reported frustration does not prove the chosen solution is best. A clear description supports review; it does not replace reading and testing the change.
Practical reader check
- Evidence: Explain the user or system difficulty and the evidence that makes the change worth reviewing.
- Boundary: A reported frustration does not prove the chosen solution is best.
- Application: Students with many assignments must scan a long list to find work due this week. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “State the Problem Before the Implementation” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to school software projects, open source, engineering teams, research code, data pipelines, website maintenance, product development, design systems and technical internships without guaranteeing grades, approval, merge, research validity, project success, employment or future outcomes.
CHAPTER 2 OF 12
2. Define the Intended Outcome
Why this move matters
Say what should become easier, safer or more accurate in observable terms.
Did You Know? An outcome gives the review a target.
Begin with the reviewer’s decision problem
Say what should become easier, safer or more accurate in observable terms. For A student can filter visible assignments by due week without changing permissions or due dates., explain the user or system problem, why this approach was chosen and what is deliberately outside the request.
Map claims to visible changes and tests
Name affected areas, test evidence, screenshots or reproducible checks so the reviewer can verify the result. Preserve this limit: Avoid promising engagement or grade gains that the change cannot establish.
Surface risk, migration and review attention
Point reviewers to high-risk files, changed defaults, data effects, accessibility concerns, rollout or follow-up rather than hiding them in a large diff.
Keep the description current through review
Update material scope changes, answer comments and record the final decision without rewriting away important history. Avoid promising engagement or grade gains that the change cannot establish. A clear description supports review; it does not replace reading and testing the change.
Practical reader check
- Evidence: Say what should become easier, safer or more accurate in observable terms.
- Boundary: Avoid promising engagement or grade gains that the change cannot establish.
- Application: A student can filter visible assignments by due week without changing permissions or due dates. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Define the Intended Outcome” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to school software projects, open source, engineering teams, research code, data pipelines, website maintenance, product development, design systems and technical internships without guaranteeing grades, approval, merge, research validity, project success, employment or future outcomes.
CHAPTER 3 OF 12
3. Draw the Scope and Non-Scope
Why this move matters
List the included components and the related work deliberately excluded from this request.
Did You Know? Boundaries reduce accidental review drift.
Begin with the reviewer’s decision problem
List the included components and the related work deliberately excluded from this request. For The request covers filtering and keyboard focus but excludes notification settings and calendar export., explain the user or system problem, why this approach was chosen and what is deliberately outside the request.
Map claims to visible changes and tests
Name affected areas, test evidence, screenshots or reproducible checks so the reviewer can verify the result. Preserve this limit: Non-scope should not hide a necessary safety dependency.
Surface risk, migration and review attention
Point reviewers to high-risk files, changed defaults, data effects, accessibility concerns, rollout or follow-up rather than hiding them in a large diff.
Keep the description current through review
Update material scope changes, answer comments and record the final decision without rewriting away important history. Non-scope should not hide a necessary safety dependency. A clear description supports review; it does not replace reading and testing the change.
Practical reader check
- Evidence: List the included components and the related work deliberately excluded from this request.
- Boundary: Non-scope should not hide a necessary safety dependency.
- Application: The request covers filtering and keyboard focus but excludes notification settings and calendar export. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Draw the Scope and Non-Scope” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to school software projects, open source, engineering teams, research code, data pipelines, website maintenance, product development, design systems and technical internships without guaranteeing grades, approval, merge, research validity, project success, employment or future outcomes.
CHAPTER 4 OF 12
4. Summarise the Approach and Alternatives
Why this move matters
Describe the main design or technical choice and why it was preferred over credible alternatives.
Did You Know? Rationale makes trade-offs reviewable.
Begin with the reviewer’s decision problem
Describe the main design or technical choice and why it was preferred over credible alternatives. For The filter uses existing assignment data rather than adding a second server query., explain the user or system problem, why this approach was chosen and what is deliberately outside the request.
Map claims to visible changes and tests
Name affected areas, test evidence, screenshots or reproducible checks so the reviewer can verify the result. Preserve this limit: A description need not reproduce every design discussion.
Surface risk, migration and review attention
Point reviewers to high-risk files, changed defaults, data effects, accessibility concerns, rollout or follow-up rather than hiding them in a large diff.
Keep the description current through review
Update material scope changes, answer comments and record the final decision without rewriting away important history. A description need not reproduce every design discussion. A clear description supports review; it does not replace reading and testing the change.
Practical reader check
- Evidence: Describe the main design or technical choice and why it was preferred over credible alternatives.
- Boundary: A description need not reproduce every design discussion.
- Application: The filter uses existing assignment data rather than adding a second server query. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Summarise the Approach and Alternatives” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to school software projects, open source, engineering teams, research code, data pipelines, website maintenance, product development, design systems and technical internships without guaranteeing grades, approval, merge, research validity, project success, employment or future outcomes.
CHAPTER 5 OF 12
5. Map the Important Changes
Why this move matters
Group the affected interface, logic, data, documentation and tests rather than listing raw filenames.
Did You Know? Change groups guide the reviewer through the diff.
Begin with the reviewer’s decision problem
Group the affected interface, logic, data, documentation and tests rather than listing raw filenames. For The description separates filter controls, query logic, accessibility labels and automated tests., explain the user or system problem, why this approach was chosen and what is deliberately outside the request.
Map claims to visible changes and tests
Name affected areas, test evidence, screenshots or reproducible checks so the reviewer can verify the result. Preserve this limit: A generated file list is not a conceptual map.
Surface risk, migration and review attention
Point reviewers to high-risk files, changed defaults, data effects, accessibility concerns, rollout or follow-up rather than hiding them in a large diff.
Keep the description current through review
Update material scope changes, answer comments and record the final decision without rewriting away important history. A generated file list is not a conceptual map. A clear description supports review; it does not replace reading and testing the change.
Practical reader check
- Evidence: Group the affected interface, logic, data, documentation and tests rather than listing raw filenames.
- Boundary: A generated file list is not a conceptual map.
- Application: The description separates filter controls, query logic, accessibility labels and automated tests. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Map the Important Changes” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to school software projects, open source, engineering teams, research code, data pipelines, website maintenance, product development, design systems and technical internships without guaranteeing grades, approval, merge, research validity, project success, employment or future outcomes.
CHAPTER 6 OF 12
6. Call Out Changed Behaviour and Compatibility
Why this move matters
Name defaults, interfaces, migrations, permissions or dependencies that behave differently.
Did You Know? Explicit behaviour reduces surprises.
Begin with the reviewer’s decision problem
Name defaults, interfaces, migrations, permissions or dependencies that behave differently. For The default remains All assignments, so saved links continue to open the same view., explain the user or system problem, why this approach was chosen and what is deliberately outside the request.
Map claims to visible changes and tests
Name affected areas, test evidence, screenshots or reproducible checks so the reviewer can verify the result. Preserve this limit: Compatibility claims must match supported environments.
Surface risk, migration and review attention
Point reviewers to high-risk files, changed defaults, data effects, accessibility concerns, rollout or follow-up rather than hiding them in a large diff.
Keep the description current through review
Update material scope changes, answer comments and record the final decision without rewriting away important history. Compatibility claims must match supported environments. A clear description supports review; it does not replace reading and testing the change.
Practical reader check
- Evidence: Name defaults, interfaces, migrations, permissions or dependencies that behave differently.
- Boundary: Compatibility claims must match supported environments.
- Application: The default remains All assignments, so saved links continue to open the same view. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Call Out Changed Behaviour and Compatibility” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to school software projects, open source, engineering teams, research code, data pipelines, website maintenance, product development, design systems and technical internships without guaranteeing grades, approval, merge, research validity, project success, employment or future outcomes.
CHAPTER 7 OF 12
7. Report Testing as Evidence
Why this move matters
List the test environment, cases, results and important gaps, linking maintained evidence where permitted.
Did You Know? Bounded evidence helps reviewers judge confidence.
Begin with the reviewer’s decision problem
List the test environment, cases, results and important gaps, linking maintained evidence where permitted. For Unit tests cover week boundaries; keyboard and screen-reader checks cover the filter; offline mode is not tested., explain the user or system problem, why this approach was chosen and what is deliberately outside the request.
Map claims to visible changes and tests
Name affected areas, test evidence, screenshots or reproducible checks so the reviewer can verify the result. Preserve this limit: “All tests pass” does not reveal what was tested.
Surface risk, migration and review attention
Point reviewers to high-risk files, changed defaults, data effects, accessibility concerns, rollout or follow-up rather than hiding them in a large diff.
Keep the description current through review
Update material scope changes, answer comments and record the final decision without rewriting away important history. “All tests pass” does not reveal what was tested. A clear description supports review; it does not replace reading and testing the change.
Practical reader check
- Evidence: List the test environment, cases, results and important gaps, linking maintained evidence where permitted.
- Boundary: “All tests pass” does not reveal what was tested.
- Application: Unit tests cover week boundaries; keyboard and screen-reader checks cover the filter; offline mode is not tested. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Report Testing as Evidence” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to school software projects, open source, engineering teams, research code, data pipelines, website maintenance, product development, design systems and technical internships without guaranteeing grades, approval, merge, research validity, project success, employment or future outcomes.
CHAPTER 8 OF 12
8. Use Screenshots and Demonstrations Safely
Why this move matters
Show before-and-after states or interaction evidence with meaningful captions and redacted data.
Did You Know? Visual evidence must remain privacy-aware and accessible.
Begin with the reviewer’s decision problem
Show before-and-after states or interaction evidence with meaningful captions and redacted data. For A synthetic assignment list demonstrates the filter at desktop and narrow widths., explain the user or system problem, why this approach was chosen and what is deliberately outside the request.
Map claims to visible changes and tests
Name affected areas, test evidence, screenshots or reproducible checks so the reviewer can verify the result. Preserve this limit: Screenshots can expose names, courses, tokens or locations.
Surface risk, migration and review attention
Point reviewers to high-risk files, changed defaults, data effects, accessibility concerns, rollout or follow-up rather than hiding them in a large diff.
Keep the description current through review
Update material scope changes, answer comments and record the final decision without rewriting away important history. Screenshots can expose names, courses, tokens or locations. A clear description supports review; it does not replace reading and testing the change.
Practical reader check
- Evidence: Show before-and-after states or interaction evidence with meaningful captions and redacted data.
- Boundary: Screenshots can expose names, courses, tokens or locations.
- Application: A synthetic assignment list demonstrates the filter at desktop and narrow widths. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Use Screenshots and Demonstrations Safely” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to school software projects, open source, engineering teams, research code, data pipelines, website maintenance, product development, design systems and technical internships without guaranteeing grades, approval, merge, research validity, project success, employment or future outcomes.
CHAPTER 9 OF 12
9. Surface Risks, Rollout and Recovery
Why this move matters
Describe plausible failure modes, affected users, monitoring, feature flags or rollback where relevant.
Did You Know? Risk language focuses attention before merge.
Begin with the reviewer’s decision problem
Describe plausible failure modes, affected users, monitoring, feature flags or rollback where relevant. For A boundary-date bug could hide Sunday assignments, so the review highlights locale tests and a fast disable path., explain the user or system problem, why this approach was chosen and what is deliberately outside the request.
Map claims to visible changes and tests
Name affected areas, test evidence, screenshots or reproducible checks so the reviewer can verify the result. Preserve this limit: Do not invent a rollback that has not been tested or authorised.
Surface risk, migration and review attention
Point reviewers to high-risk files, changed defaults, data effects, accessibility concerns, rollout or follow-up rather than hiding them in a large diff.
Keep the description current through review
Update material scope changes, answer comments and record the final decision without rewriting away important history. Do not invent a rollback that has not been tested or authorised. A clear description supports review; it does not replace reading and testing the change.
Practical reader check
- Evidence: Describe plausible failure modes, affected users, monitoring, feature flags or rollback where relevant.
- Boundary: Do not invent a rollback that has not been tested or authorised.
- Application: A boundary-date bug could hide Sunday assignments, so the review highlights locale tests and a fast disable path. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Surface Risks, Rollout and Recovery” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to school software projects, open source, engineering teams, research code, data pipelines, website maintenance, product development, design systems and technical internships without guaranteeing grades, approval, merge, research validity, project success, employment or future outcomes.
CHAPTER 10 OF 12
10. Ask for Specific Review Attention
Why this move matters
Point to uncertain decisions, sensitive areas and the reviewers whose expertise is needed.
Did You Know? A focused request improves review quality.
Begin with the reviewer’s decision problem
Point to uncertain decisions, sensitive areas and the reviewers whose expertise is needed. For The author asks one reviewer to verify date boundaries and another to check accessible naming., explain the user or system problem, why this approach was chosen and what is deliberately outside the request.
Map claims to visible changes and tests
Name affected areas, test evidence, screenshots or reproducible checks so the reviewer can verify the result. Preserve this limit: Reviewer mentions should follow team workload and ownership rules.
Surface risk, migration and review attention
Point reviewers to high-risk files, changed defaults, data effects, accessibility concerns, rollout or follow-up rather than hiding them in a large diff.
Keep the description current through review
Update material scope changes, answer comments and record the final decision without rewriting away important history. Reviewer mentions should follow team workload and ownership rules. A clear description supports review; it does not replace reading and testing the change.
Practical reader check
- Evidence: Point to uncertain decisions, sensitive areas and the reviewers whose expertise is needed.
- Boundary: Reviewer mentions should follow team workload and ownership rules.
- Application: The author asks one reviewer to verify date boundaries and another to check accessible naming. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Ask for Specific Review Attention” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to school software projects, open source, engineering teams, research code, data pipelines, website maintenance, product development, design systems and technical internships without guaranteeing grades, approval, merge, research validity, project success, employment or future outcomes.
CHAPTER 11 OF 12
11. Keep the Description Current
Why this move matters
Update the summary and evidence when review materially changes scope, behaviour or test results.
Did You Know? The top description should match the current proposal.
Begin with the reviewer’s decision problem
Update the summary and evidence when review materially changes scope, behaviour or test results. For After feedback changes week boundaries, the description and screenshot are revised with a dated note., explain the user or system problem, why this approach was chosen and what is deliberately outside the request.
Map claims to visible changes and tests
Name affected areas, test evidence, screenshots or reproducible checks so the reviewer can verify the result. Preserve this limit: Do not erase the conversation or pretend the original approach never existed.
Surface risk, migration and review attention
Point reviewers to high-risk files, changed defaults, data effects, accessibility concerns, rollout or follow-up rather than hiding them in a large diff.
Keep the description current through review
Update material scope changes, answer comments and record the final decision without rewriting away important history. Do not erase the conversation or pretend the original approach never existed. A clear description supports review; it does not replace reading and testing the change.
Practical reader check
- Evidence: Update the summary and evidence when review materially changes scope, behaviour or test results.
- Boundary: Do not erase the conversation or pretend the original approach never existed.
- Application: After feedback changes week boundaries, the description and screenshot are revised with a dated note. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Keep the Description Current” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to school software projects, open source, engineering teams, research code, data pipelines, website maintenance, product development, design systems and technical internships without guaranteeing grades, approval, merge, research validity, project success, employment or future outcomes.
CHAPTER 12 OF 12
12. Close With Decision and Follow-Up
Why this move matters
After merge or closure, preserve the final outcome, unresolved work and linked next items without overclaiming completion.
Did You Know? A clear ending helps the next maintainer.
Begin with the reviewer’s decision problem
After merge or closure, preserve the final outcome, unresolved work and linked next items without overclaiming completion. For The merged request notes that offline filtering remains a separate issue., explain the user or system problem, why this approach was chosen and what is deliberately outside the request.
Map claims to visible changes and tests
Name affected areas, test evidence, screenshots or reproducible checks so the reviewer can verify the result. Preserve this limit: Merge is not proof of production success.
Surface risk, migration and review attention
Point reviewers to high-risk files, changed defaults, data effects, accessibility concerns, rollout or follow-up rather than hiding them in a large diff.
Keep the description current through review
Update material scope changes, answer comments and record the final decision without rewriting away important history. Merge is not proof of production success. A clear description supports review; it does not replace reading and testing the change.
Practical reader check
- Evidence: After merge or closure, preserve the final outcome, unresolved work and linked next items without overclaiming completion.
- Boundary: Merge is not proof of production success.
- Application: The merged request notes that offline filtering remains a separate issue. Name the next output and how it will be checked.
Student, parent and career transfer
Practise “Close With Decision and Follow-Up” by separating evidence, interpretation, decision and next action. A parent, teacher, supervisor or teammate can ask what supports the sentence and which missing fact could change it. This discipline transfers to school software projects, open source, engineering teams, research code, data pipelines, website maintenance, product development, design systems and technical internships without guaranteeing grades, approval, merge, research validity, project success, employment or future outcomes.
PRACTICE LAB
Build a pull request description decision trail
Student route
- Choose one real example or official document inside this guide’s scope.
- Copy its objective and underline actor, action, context, evidence and intended decision.
- Draw the specific reasoning chain used in this article.
- Mark each step reported, inferred, contested or unknown.
- Rewrite the conclusion so it preserves the narrowest important limitation.
Parent or teacher route
Ask the learner to explain help a reviewer understand the problem, boundaries, approach, evidence and risk of a proposed change before they enter the diff—and keep that shared map accurate through review twice: once to a classmate and once to a method specialist. Praise a precise correction and a well-stated unknown; both show disciplined attention to evidence.
Early-career route
Create a one-page pull request description audit with source link, date checked, scope, method logic, decisive wording, contrary evidence, limit and next action. A colleague should be able to continue without guessing.
Decision rule
If a shorter explanation removes the condition that made the original claim true, it is not clearer yet. Restore the condition.
Continue with eduKate’s guides to reading course and career information and giving useful feedback in group projects.
USEFUL NEXT READING
Connect this narrow owner to its neighbour
Read the code-review comments guide for a related but different reader job. Return here when the question is specifically how to help a reviewer understand the problem, boundaries, approach, evidence and risk of a proposed change before they enter the diff—and keep that shared map accurate through review. Use each guide for the reader task named in its heading.
For English practice across research, school and career communication, visit the Singapore English Tuition Centre learning site.
FREQUENTLY ASKED QUESTIONS
Questions students and parents often ask
How long should a pull request description be?
Long enough to explain problem, scope, evidence and risk, but structured so reviewers can find what matters quickly.
Should I copy every commit message into it?
No. Summarise the coherent proposal; link or reference history when it adds necessary context.
What tests should I list?
Name the relevant environments, cases, results and gaps rather than using an unqualified “tested”.
Are screenshots always needed?
They are useful for visual or interaction changes when safe, accessible and based on synthetic or redacted data.
Should I update the description after review?
Yes when scope, behaviour, evidence or risk changes materially, while preserving the review conversation.
Does a strong description make a pull request safe to merge?
No. Reviewers still need to inspect the diff, tests, policies, dependencies and approvals.
PRIMARY SOURCES
Read the primary guidance for this pull request description
Facts were checked against current official and primary sources on 9 November 2026. Follow the live source for later corrections, completed updates or companion material.
- GitHub Docs helping others review changes
- GitHub Docs about pull requests
- GitHub Docs pull-request templates
- eduKate code-review comments guide
- eduKate software test-case guide
A cheerful final note
Precise English makes help a reviewer understand the problem, boundaries, approach, evidence and risk of a proposed change before they enter the diff—and keep that shared map accurate through review more generous, not less. People can see how their evidence and values entered the work, where disagreement remains and what a responsible next step looks like.