What level of review does this pull request require?

{
  "_meta": {
    "schema": "https://www.drawdecisiontree.com/decision-dag.schema.json",
    "source": "https://www.drawdecisiontree.com",
    "description": "DrawDecisionTree.com is a free tool for building, sharing, and embedding interactive decision trees. This file is the machine-readable export of a published decision tree. The `dsl` field contains the original source in the Decision DAG DSL; the `dag` schema is documented at the URL in `schema` above.",
    "links": {
      "interactive": "https://www.drawdecisiontree.com/t/drawdecisiontree/engineering-pr-review.html",
      "embed": "https://www.drawdecisiontree.com/embed/path/drawdecisiontree/engineering-pr-review",
      "dsl_reference": "https://www.drawdecisiontree.com/decision-tree-dsl-reference.html",
      "guides": "https://www.drawdecisiontree.com/guides",
      "schema_docs": "https://www.drawdecisiontree.com/decision-dag.schema.json",
      "author_trees": "https://www.drawdecisiontree.com/trees/drawdecisiontree"
    },
    "generated_at": "2026-05-29T12:05:39.284Z"
  },
  "author": {
    "handle": "drawdecisiontree",
    "first_name": "Andrew",
    "last_name": null,
    "avatar_url": "1d32d828-b6ca-40ec-bdd7-771fe7b9c36a/avatar-1778531481027.svg",
    "display_name": "Andrew"
  },
  "file": {
    "id": "b290c03e-5a69-4773-81e1-af7979de9cbf",
    "name": "What level of review does this pull request require?",
    "public_slug": "engineering-pr-review",
    "updated_at": "2026-05-12T16:53:43.587978+00:00",
    "url": "https://www.drawdecisiontree.com/t/drawdecisiontree/engineering-pr-review.html",
    "json_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/engineering-pr-review/tree.json",
    "dsl_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/engineering-pr-review/tree.dag"
  },
  "meta": {
    "description": "Applying the same review process to every pull request wastes senior engineering time on trivial changes and under-scrutinises high-risk ones. This tree helps engineers and tech leads determine the appropriate level of review—from self-merge for genuine production hotfixes to full architect sign-off for cross-cutting changes—based on urgency, size, risk, and service boundaries.",
    "mode": "decision",
    "entry": "Q1",
    "tags": [
      "engineering",
      "code review",
      "pull requests",
      "software quality",
      "devops"
    ],
    "image": "https://images.unsplash.com/photo-1556075798-4825dfaaf498?w=1200&q=80"
  },
  "questions": [
    {
      "id": "Q1",
      "text": "Is this a production hotfix for a live incident where every minute of delay has measurable customer impact?"
    },
    {
      "id": "Q2",
      "text": "Does this change touch authentication, authorisation, payments, encryption, or core data models?"
    },
    {
      "id": "Q3",
      "text": "Does this change cross service boundaries, introduce new external dependencies, or modify shared infrastructure?"
    },
    {
      "id": "Q4",
      "text": "How many lines of code (excluding generated files, lock files, and vendor directories) are changed?"
    },
    {
      "id": "Q5",
      "text": "How would you rate the overall risk of this change?"
    }
  ],
  "outcomes": [
    {
      "id": "SELF_MERGE",
      "label": "Author Can Self-Merge (Hotfix)"
    },
    {
      "id": "ONE_REVIEWER",
      "label": "One Reviewer Required"
    },
    {
      "id": "TWO_REVIEWERS",
      "label": "Two Reviewers Required"
    },
    {
      "id": "ARCHITECT",
      "label": "Requires Senior/Architect Sign-off"
    }
  ],
  "dsl": "dag: What level of review does this pull request require?\nversion: 1.0.0\nimage: https://images.unsplash.com/photo-1556075798-4825dfaaf498?w=1200&q=80\ndescription: Applying the same review process to every pull request wastes senior engineering time on trivial changes and under-scrutinises high-risk ones. This tree helps engineers and tech leads determine the appropriate level of review—from self-merge for genuine production hotfixes to full architect sign-off for cross-cutting changes—based on urgency, size, risk, and service boundaries.\ntags: engineering, code review, pull requests, software quality, devops\nentry: Q1\n\nQ1: Is this a production hotfix for a live incident where every minute of delay has measurable customer impact?\n  hint: A hotfix justifies an accelerated review process only when there is an active, confirmed production incident and the change is the minimal delta required to restore service. It is not a hotfix just because it feels urgent—if the system is degraded but not down, or the fix is more than a handful of lines, use the standard process. Document the incident ticket number in the PR description so the bypass is auditable. After the incident is resolved, the change must go through a standard post-incident review within 48 hours.\n  yes -> [SELF_MERGE]\n  no  -> Q2\n\nQ2: Does this change touch authentication, authorisation, payments, encryption, or core data models?\n  hint: These domains carry disproportionate risk: a bug in an auth flow can expose all user data; a payment logic error can cause financial loss or regulatory liability; a schema migration on a core table can take down the entire platform. Even small changes in these areas—a one-line conditional, a new index, a permission check—deserve heightened scrutiny. When in doubt, err on the side of treating a change as high-risk.\n  yes -> [ARCHITECT]\n  no  -> Q3\n\nQ3: Does this change cross service boundaries, introduce new external dependencies, or modify shared infrastructure?\n  hint: Cross-boundary changes—adding a new inter-service API call, changing a shared library consumed by multiple services, modifying CI/CD pipeline configuration, or altering infrastructure-as-code—affect teams beyond the author's immediate squad. These changes require reviewers who understand the downstream blast radius, not just the immediate codebase. \"Shared infrastructure\" includes databases, message queues, API gateways, authentication services, and monitoring configuration.\n  when: Q2=no\n  yes -> [TWO_REVIEWERS]\n  no  -> Q4\n\nQ4: How many lines of code (excluding generated files, lock files, and vendor directories) are changed?\n  hint: Line count is an imperfect but practical proxy for review complexity. Generated files, package lock files, and vendored dependencies should be excluded from this count—they are rarely the site of meaningful defects. For changes near the thresholds, use your judgement: a 200-line change that is a straightforward data migration may need less scrutiny than a 40-line change that restructures core business logic.\n  A: Fewer than 200 lines changed -> Q5\n  B: 200 lines or more changed -> [TWO_REVIEWERS]\n\nQ5: How would you rate the overall risk of this change?\n  hint: Consider factors beyond the raw risk domains from Q2: Does this change a user-visible behaviour or API contract? Does it modify error handling or retry logic? Does it touch code with low test coverage? Does it rely on environment-specific configuration that differs between staging and production? A change that is small and isolated in a well-tested, low-criticality module can reasonably proceed with one reviewer; the same size change in a murky, under-tested module may warrant two.\n  when: Q4=A\n  A: Low risk — isolated, well-tested, no user-visible behaviour change -> [ONE_REVIEWER]\n  B: Medium or high risk — some uncertainty, limited tests, or visible behaviour change -> [TWO_REVIEWERS]\n\n[SELF_MERGE]: Author Can Self-Merge (Hotfix)\n  color: #dc2626\n  description: Self-merge is authorised only for confirmed production incidents where the change restores service and the delay of a review would materially worsen customer impact. Keep the change absolutely minimal—revert or toggle a flag where possible rather than writing new logic under pressure. Paste the incident ticket link and a one-paragraph explanation of the fix into the PR description before merging. Immediately notify your team in the incident channel that a self-merge has occurred. Schedule a post-incident review within 48 hours where the change undergoes full retrospective scrutiny and any follow-up hardening work is ticketed.\n  code: ENG_PRR_SELF\n\n[ONE_REVIEWER]: One Reviewer Required\n  color: #16a34a\n  description: One peer reviewer is the standard for low-risk, bounded changes: small features, bug fixes in well-tested code, documentation updates, and configuration tweaks that do not cross service boundaries. The reviewer should be a team member with familiarity with the affected codebase—not just someone who is available. Aim for a review turnaround of one business day; PRs that sit unreviewed for more than two days should be flagged in the team's daily standup. The author is responsible for ensuring all CI checks pass and the change is demonstrably tested before requesting review.\n  code: ENG_PRR_ONE\n\n[TWO_REVIEWERS]: Two Reviewers Required\n  color: #ea580c\n  description: Two independent reviewers are required for larger or cross-cutting changes where a single pair of eyes is insufficient to catch all failure modes. At least one reviewer must have domain familiarity with the affected system; the second can be a generalist engineer focused on code quality, test coverage, and maintainability. Both reviewers must approve before merge—do not merge on one approval with the intention of addressing the second reviewer's comments afterwards. If the change spans multiple services, ensure at least one reviewer represents each affected service's team. Target a 48-hour review cycle; if reviewers cannot be found within that window, escalate to the tech lead to reprioritise.\n  code: ENG_PRR_TWO\n\n[ARCHITECT]: Requires Senior/Architect Sign-off\n  color: #7c3aed\n  description: Changes touching authentication, payments, encryption, or core data models require sign-off from a senior engineer or architect with explicit expertise in the affected domain—not just any senior engineer. Prepare a written design note or architecture decision record (ADR) summarising the change, the alternatives considered, and the security and data-integrity implications; attach it to the PR. The architecture review should be synchronous (a 30-minute call is often more effective than asynchronous comments on complex security changes). Allow at least three business days for this review in your sprint planning; rushing security-sensitive changes through is how serious vulnerabilities are introduced. After merge, ensure the relevant runbook and threat model are updated.\n  code: ENG_PRR_ARCH\n"
}