Beyond Maintainer Inconsistency: Using Review Archetypes to Navigate OSS Review

You opened a pull request. It sat for weeks in review while a similar-sized change merged in days. It is tempting to blame maintainer's inconsistency or assume you simply lost the "Reviewer Lottery." That assumption changes how contributors rewrite code, interpret feedback, and prepare future pull requests.
This talk argues that contributors often explain review outcomes at the wrong level. Rather than being primarily driven by individual maintainer behaviour, review pathways in mature open-source projects are frequently shaped by structural governance: ownership boundaries, approval responsibilities, and how review authority is distributed across the project.
Using Kubernetes as a case study, I reconstruct the approval chains, ownership boundaries, and review discussions of two contrasting pull requests: an infrastructure-focused change (PR #139970) and a cross-domain feature integration (PR #137964). Although the technical changes are very different, the comparison reveals something more interesting than code complexity: the way review authority moves through the project's ownership structure.
From these observations, I distill two Review Archetypes that contributors can use as a practical heuristic for understanding review behaviour.

• Boundary-Contained Review: the change remains within a single ownership boundary, allowing review authority to stay concentrated within one domain.

• Boundary-Spanning Review: The change crosses multiple ownership boundaries, requiring coordinated approval from several domain experts before the work can move forward.
  The goal of this framework is not to explain every review process or propose a universal taxonomy of open-source governance. Instead, it offers contributors a practical mental model for reasoning about projects with explicit ownership structures. Rather than asking "Why is this maintainer making my review difficult?", contributors learn to ask "How many ownership boundaries does my change cross, and how will that shape the review?"

• 
  Attendees will leave with a repeatable approach for analysing ownership structure before opening a pull request, anticipating the review pathway their change is likely to follow, and preparing the architectural context needed for efficient cross-domain review.

•  Kubernetes serves as the primary case study because its explicit ownership model and public review history make governance pathways observable. The framework is presented as a contributor heuristic for projects with explicit ownership structures rather than as a comprehensive theory of open-source governance.
  
  

• Correct the Mental Model: Understand why review outcomes are often attributed to maintainer behaviour when they are better explained by project governance.

• Recognise Two Review Archetypes Learn: how Boundary-Contained and Boundary-Spanning reviews emerge from ownership structure rather than code complexity.

• Read Governance Through Project Structure: Learn how directory ownership, approval responsibilities, and review authority shape the path a pull request follows.

• Apply the Diagnostic Heuristic: Evaluate your pull requests by asking:
  

  • Does this change remain within one ownership boundary or cross multiple ownership domains?

  • Will review authority remain concentrated, or require coordination across multiple domain owners?

• Improve Contributor Workflow: Use this heuristic to anticipate review participants, prepare the right architectural context before requesting review, and audit your project's review history to understand how governance influences review practice.