Code Review Acronyms Explained: LGTM, PTAL, NIT, RFC, ACK/NACK
Quick answer
Code review acronyms compress intent: LGTM/Ship It = ready to merge, PTAL = please review soon, NIT = non-blocking polish, ACK/NACK = agree/disagree with a point, RFC = request feedback on direction, WIP/Draft = early PR, TBD/TODO = follow-up work (ideally cleared before approval), ICYMI/TL;DR = fast summaries for reviewers. Use them consistently, pair them with blocking/non-blocking labels, and back them with automated checks so phrases always match policy.
LGTM is the headliner, but teams lean on a dozen small acronyms to speed reviews. When everyone uses them the same way, pull requests move faster and approvals carry clear intent. When they are inconsistent, reviews stall, optional work lingers, and merges happen without the right guardrails. This guide explains the common phrases, how to use them, and how to pair them with policy so they never drift.
The acronyms at a glance
- LGTM / Ship It: Formal approval. No blockers remain. Pairs with merge policy. See LGTM meaning and Ship It.
- PTAL: Please take a look. Signals urgency or a targeted reviewer.
- NIT: Non-blocking polish. See nit etiquette.
- ACK / NACK: Agree or disagree with feedback; NACK should include a brief rationale.
- RFC: Request for comments. Ask for direction on approach, not line-level nits.
- WIP / Draft: Early PR meant for high-level feedback only.
- TBD / TODO: Follow-up work; ideally cleared or ticketed before merge.
- ICYMI / TL;DR: Summaries to help reviewers ramp faster.
Reviewer intent: LGTM, Ship It, ACK/NACK
LGTM/Ship It should line up with your approval rules. Use them when blocking threads are resolved, tests are green, and rollout or migration steps are clear. ACK acknowledges feedback and keeps the thread unblocked. NACK is a polite disagreement—pair it with a short reason or an alternative suggestion so the author knows how to proceed.
If you approve with follow-ups, make the non-blocking nature explicit: “LGTM + follow-up issue https://…” or “Ship It after docs PR lands.” That keeps approvals honest while letting teams merge quickly.
Asking for attention: PTAL, ICYMI
PTAL is a targeted ping. Use it sparingly, ideally after updating the PR with requested changes or addressing a critical fix. If you need rapid eyes, include the why: “PTAL @alice for security check before freeze.” ICYMI works best as a short update when the diff changed materially: “ICYMI: switched to streaming API; risk is lower now.”
PR state: WIP/Draft and RFC
WIP/Draft tells reviewers to focus on architecture, not nits. Keep these small and remove WIP once the shape is locked. RFC asks for directional input before deep implementation. Include context, options considered, and open questions so reviewers can give useful guidance.
Severity: NIT and blocking vs. non-blocking
NIT marks non-blocking polish. If the comment is blocking, skip the NIT label and say “Blocking: …”. Mixing the two creates confusion. For a fast lane, group cosmetic nits in one comment to reduce noise.
Follow-ups: TBD/TODO with discipline
TBD/TODO can’t be a parking lot. Either address them before approval or attach them to a ticket and reference it in the PR. Otherwise, they become invisible debt that slows future reviews.
Summaries: TL;DR for faster reviews
A concise TL;DR at the top of the PR or in a comment reduces review time. Include: what changed, why, risk level, tests, and rollout plan. Add ICYMIupdates if the PR evolves.
Copy-paste snippets
- PTAL: “PTAL @owner — need security sign-off before Thursday deploy.”
- NIT: “NIT: rename to clarify intent (non-blocking).”
- ACK: “ACK, updated tests accordingly.”
- NACK: “NACK: breaks multi-tenant path; suggest using feature flag instead.”
- LGTM + follow-up: “LGTM. Logged TODO as PROJ-123; safe to merge now.”
- TL;DR: “TL;DR — swapped sync API for streaming; risk: low; tests: e2e + perf; rollout: 10% canary.”
Make the acronyms enforceable
Shorthand only works when it is backed by policy and tooling. Use codeowners to route PTALs, label blocking vs. non-blocking comments, and track follow-ups. Propel Code classifies reviewer intent, enforces approval policies, and keeps optional cleanup from stalling merges so LGTM and Ship It always match reality.
Ready to Transform Your Code Review Process?
See how Propel's AI-powered code review helps engineering teams ship better code faster with intelligent analysis and actionable feedback.
