Example written review of one pull request: findings, labels and a not-examined list

This review is synthetic

The shop, the pull request, the files and every finding below are invented. The example shows the format a buyer should expect: each finding has a place, a problem, a reason, a severity and a way to verify it, and is labelled shown or suspected. It is not the result of reviewing any real code, and a real review quotes the actual change.

If the matrix is wider than the box, scroll horizontally to read every column. Keyboard: focus the matrix and use Left/Right.

SYNTHETIC EXAMPLE: pull request "Add discount codes to the basket" in an invented shop.
Intent given by the author: customers can enter one code that lowers the basket total.
Standard applied: improves overall code health; facts over preference; nits are optional.

FINDING 1   HIGH   SHOWN
  Place     basket/discounts.py, line 58
  Problem   two codes can be applied together, and the total can fall below zero
  Reason    the intent says one code; a negative total reaches the payment step
  Verify    failing test test_two_codes_cannot_exceed_total (attached); it fails on this branch

FINDING 2   MEDIUM   SUSPECTED
  Place     basket/discounts.py, lines 31 to 44
  Problem   code lookup may be case-sensitive, so "SAVE10" and "save10" behave differently
  Reason    customers type codes by hand
  Verify    enter both spellings in the staging basket; not yet run

FINDING 3   MEDIUM   SHOWN
  Place     tests/test_discounts.py
  Problem   no test covers an expired code
  Reason    the change adds an expiry date; nothing would notice if it were ignored
  Verify    delete the expiry check on a copy; all tests still pass (output attached)

FINDING 4   NIT   (optional)
  Place     basket/discounts.py, line 12
  Problem   the name apply_it does not say what it applies

DONE WELL   the code is applied in one place, and the rounding follows the existing rule

NOT EXAMINED
  - the payment provider integration
  - behaviour with real customer data or production settings
  - performance with large baskets
  - browsers and devices

This review informs your decision. It is not an approval, and it does not say the change is safe to run in production.

What each part does

Place and problem let the author find the code without asking. Reason ties the finding to the stated intent, so it is not a matter of taste. Severity helps the author decide what to fix before merging. Verification is what separates a shown finding from a suspicion: a failing test or a traced input that anyone can run. A suspected finding is labelled as such, so nobody treats a hunch as a fact. The nit is marked optional, following the published practice that minor points may be skipped.

• Findings are ordered by severity, not by the order of files.
• Something done well is recorded as well, because it tells the author what to keep.

Why the not-examined list matters

A review of a few areas can look like a review of everything. The not-examined list says plainly which areas were not looked at, so a clean result is read as no findings in the areas examined and never as approval. The closing sentence repeats it. The written-findings job requires a list like this for every pull request and a second reader who checks the wording for anything that sounds like approval.

Limits

A single synthetic pull request cannot show how a real review handles a large change, an unfamiliar framework or unclear intent. In practice we ask the author what the change is for, say when intent is unclear and stop short of guessing. A review lowers the chance of a defect reaching production; it cannot find all of them. Prices for the paid jobs are untested hypotheses, and nothing is charged until scope and terms are agreed in writing.