non-blocking)¶

What it is: Not a single named "theory" like the others — it's a widespread, informal convention in software engineering for prefixing review comments with a severity tag, so the recipient instantly knows whether to act on it before merging or just consider it.

Common vocabulary (varies by team/company, no single standard)¶

nit: (nitpick) — trivial, stylistic, or personal-preference feedback. Take it or leave it. Functionally identical to a low-LOGAF comment.
blocking: or must-fix: — this needs to be resolved before merge. Functionally a high-LOGAF comment.
non-blocking: or suggestion: — worth considering, not required. A mid-LOGAF comment.
question: — genuinely asking, not necessarily advocating for a change.
Some larger orgs (Google's internal review culture is the most cited example) formalize this further with explicit "LGTM with nits" conventions, where approval is granted contingent on trivial fixes.

Why teams converge on this independently¶

Code review is exactly the setting Dan Lew's original LOGAF post was written about — a PR comment thread where tone is invisible and the reviewer's actual stakes in a suggestion are ambiguous. Severity tags solve the identical problem LOGAF solves, but they're scoped narrowly to code review rather than general conversation, and they're two-tier or three-tier rather than a free-form scale.

How it differs from LOGAF¶

Severity tags are usually binary or ternary (nit vs. blocking, sometimes plus one middle tier). LOGAF is framed as a continuous low→high scale.
Severity tags are institutionalized — often written into a team's PR template or contributing guide. LOGAF, per Dan Lew's own post, is explicitly informal and meant to be invoked only occasionally, not as a fixed protocol.
Severity tags are almost entirely confined to code review / technical writing. LOGAF (in Dan Lew's usage) extends to design debates and general team disagreements, not just line-by-line comments.

Practical note¶

If you want something with more traction than LOGAF, nit: / blocking: prefixes are the path of least resistance — reviewers on GitHub/GitLab already half-recognize the convention even without a team agreement, whereas "my logaf is low" would need to be introduced and explained.