Pull Request Review Language Exercises

1 / 5

A developer opens a PR and marks it as a draft.

What does a draft PR communicate to reviewers?

Draft PR = work in progress signal:

PR state	Message to reviewers
Draft	WIP — do not do a full review yet; CI feedback welcome
Ready for review	Author believes it is complete — formal review requested

Draft → ready for review = click "Mark as ready for review". Key vocabulary: draft PR, WIP, convert to ready for review, signal for early feedback, PR readiness.

2 / 5

A reviewer writes: "nit: the variable name d should be more descriptive."

What does "nit" mean in code review vocabulary?

Code review feedback prefixes — communicating comment priority:

Prefix	Meaning	Blocks merge?
`nit:` / `nitpick:`	Minor style preference	No
`blocking:`	Must fix before merge	Yes
`[question]:`	Author asked for clarification	No
`optional:`	Take it or leave it	No

Key vocabulary: blocking vs. non-blocking feedback, nitpick, code review etiquette.

3 / 5

A reviewer clicks "Request changes" on a PR that already has 2 approvals and passing CI.

What does "requesting changes" do in GitHub/GitLab?

Review states in GitHub/GitLab:

Review state	Effect on PR
Approve	Reviewer satisfied — counts toward required approvals
Request changes	Blocks merge — reviewer must re-approve after fixes
Comment	Feedback only — no approval/block decision

Key vocabulary: review state, review blocking, re-review after addressing comments, dismissing stale reviews.

4 / 5

A PR description includes: a summary, screenshots, and a testing checklist.

Which PR description element is MOST valuable for code reviewers?

PR description best practices — Why > What:

Element	Value to reviewer
Why / Context	Not visible in the diff — essential for understanding the decision
What changed	Already visible in the diff — low added value in description
Screenshot (UI changes)	High value for UI PRs — saves reviewer time
Linked ticket	Full user story and acceptance criteria context

Key vocabulary: PR context, motivation section, approach explanation, linked issue/ticket, screenshot for UI changes.

5 / 5

A team adds a CODEOWNERS file to their repository.

What does this enable?

CODEOWNERS — automatic reviewer assignment by file path:

CODEOWNERS rule	Effect
`src/payments/ @payments-team`	`@payments-team` auto-added as required reviewer for payments changes
`*.sql @data-team`	All SQL file changes require data team review

GitHub/GitLab both support CODEOWNERS. Key vocabulary: code ownership, required reviewer, domain expert review, automatic reviewer assignment, ownership coverage gaps.