# ship-show-ask

**Ship/Show/Ask** is Rouan Wilsenach's model (published on martinfowler.com) for categorizing code changes into three buckets, each with a different review treatment. It is the intermediate step between blocking-async PRs and full [[trunk-based-development]] with pair programming.

## The three categories

- **Ship.** Merge directly to mainline without review. For routine changes where the developer is confident — typo fixes, small refactors, dependency bumps, documented patterns.
- **Show.** Open a PR, merge immediately without waiting, let review happen post-merge. For changes the author wants discussion on but isn't gated by — new code that follows existing patterns, low-risk additions, work the team should be aware of but doesn't need to bless before it lands.
- **Ask.** Open a PR and wait for review before merging. For complex or uncertain changes — architectural shifts, risky behavior, code the author isn't sure about, work that touches areas the author doesn't own.

The developer picks the category for each change. The team agrees on which categories live in which trees of the codebase or which kinds of changes.

## Why it works

The model attacks the assumption that *all* changes need blocking review. In practice, most changes don't — Fowler's client cited in [[stop-using-pull-requests]] saw 91% of PRs receive zero comments before approval, meaning 91% could have been Ship or Show without losing any review value.

By moving routine work out of the blocking review path, Ship/Show/Ask:

- Reduces the waiting tax that PRs impose (86-99% of lead time per Laforgia).
- Builds the team's muscle for *trust* — explicitly making the "I'm confident enough to ship" judgment is a skill teams atrophy when PRs are mandatory.
- Reserves Ask review for changes where review is actually load-bearing.

## Position in the transition path

Laforgia places Ship/Show/Ask at Stage 2 of the five-stage path away from PRs:

1. Optimize PRs (small, fast SLA, one approver).
2. **Ship/Show/Ask.**
3. Pair programming + trunk-based development.
4. Ensemble programming + TBD.
5. Full T\*D.

Stage 2 is the first point where the team stops treating PRs as the universal mechanism. It works without changing the IDE, the CI pipeline, or the deployment tooling — only the conventions about what each change needs.

## Caveats

- Requires the team to have **trust calibrated** — both that the Ship author won't ship something they shouldn't have, and that the Ask author isn't asking for permission they don't need.
- Requires **good post-merge review hygiene** — Show only works if someone actually reads the merged change and comments. Without that, Show degenerates into "merge and forget."
- Doesn't replace [[pair-programming]] — pair programming reviews during creation; Ship/Show/Ask reviews after. The piece treats them as complementary stages.

## Related

- [[stop-using-pull-requests]] — the larger argument in which Ship/Show/Ask is a transitional stage
- [[trunk-based-development]] — the destination Ship/Show/Ask is moving the team toward
- [[code-review-knowledge-transfer]] — what review is actually for, which shapes how to triage between Ship/Show/Ask
- [[stacked-prs]] / [[billjings-git-not-fine]] — git workflow gaps that Ship/Show/Ask sidesteps for routine changes