diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 4560e8756..2d9ebdff0 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -78,7 +78,7 @@ submitting a feature or substantial code contribution, please discuss it with th
 ensure it follows the product roadmap. You might also read these two blogs posts on contributing
 code: [Open Source Contribution Etiquette](http://tirania.org/blog/archive/2010/Dec-31.html) by Miguel de Icaza and
 [Don't "Push" Your Pull Requests](https://www.igvita.com/2011/12/19/dont-push-your-pull-requests/) by Ilya Grigorik.
-All code submissions will be rigorously reviewed and tested by the maintainers, and only those that meet
+All code submissions will be rigorously [reviewed](docs/Governance.md) and tested by the maintainers, and only those that meet
 the bar for both quality and design/roadmap appropriateness will be merged into the source.
 
 For all new Pull Requests the following rules apply:
diff --git a/docs/Governance.md b/docs/Governance.md
new file mode 100644
index 000000000..bfe02298f
--- /dev/null
+++ b/docs/Governance.md
@@ -0,0 +1,39 @@
+Project Governance
+==================
+
+Reviewing Pull Requests
+-----------------------
+
+Pull requests need at least two approvals before being eligible for merging.
+Besides reviewing for technical correctmess, reviewers are expected to:
+
+* For any PR that adds functionality, check that the PR includes sufficient tests
+  for that functionality.  This is required in [CONTRIBUTING.md](../Contributing.md).
+* For any PR that adds or changes functionality in a way that is observable
+  by administrators or by authors of eBPF programs or applications, check that
+  documentation has been sufficiently updated.  This is required in
+  [CONTRIBUTING.md](../Contributing.md).
+* Check that there are no gratuitous differences in public APIs between eBPF for
+  Windows and Linux.
+* Be familiar with, and call out code that does not conform to, the eBPF for Windows
+  [coding conventions](DevelopmentGuide.md).
+* Check that errors are appropriately logged where first detected (not at each
+  level of stack unwind).
+
+When multiple pull requests are approved, maintainers should prioritize merging PRs as follows:
+
+| Pri | Description  | Tags      | Rationale              |
+| --- | ------------ | --------- | ---------------------- |
+| 1   | Bugs         | bug       | Affects existing users |
+| 2   | Test bugs    | tests bug | Problem that affects CI/CD and may mask priority 1 bugs |
+| 3   | Additional tests | tests enhancement | Gap that once filled might surface priority 1 bugs |
+| 4   | Documentation | documentation | Won't affect CI/CD but may address usability issues |
+| 5   | Dependencies | dependencies | Often a large amount of low hanging fruit. Keeping the overall PR count low gives a better impression to newcomers and observers. |
+| 7   | New features | enhancement | Addresses functionality requested in a github issue |
+| 8   | Performance optimizations | optimization | Doesn't do anything that isn't already working, but improvements do help users |
+| 9   | Code cleanup | cleanup | Good to do but generally doesn't significantly affect any of the above categories |
+
+Release Process
+------------------
+
+See [Release Process](ReleaseProcess.md).