Add a governance policy

_config.yml

@@ -43,7 +43,7 @@ navigation:
 - text: Guidelines
   url: 'guidelines/'
   internal: true
-- text: Contact
+- text: Contact and governance
   url: 'contact/'
   internal: true
 

_pages/contact.md

@@ -1,6 +1,6 @@
 ---
 layout: default
-title: Contact
+title: Contact and governance
 ---
 
 # Contact
@@ -14,4 +14,41 @@ repository.
 
 That said, if you are interested in working with GSA's
 [18F](https://18f.gsa.gov) for hosting and customization, contact Will
-Sullivan at [will.sullivan@gsa.gov](mailto:will.sullivan@gsa.gov).
+Sullivan at [will.sullivan@gsa.gov](mailto:will.sullivan@gsa.gov) or [eregs@gsa.gov](mailto:eregs@gsa.gov).
+
+# Governance
+
+The eRegulations project began as a work of the
+[Consumer Financial Protection Bureau](https://cfpb.github.io/), but has been
+adopted by [several federal agencies](/#live-instances) with significant
+contributions from [18F](https://18f.gsa.gov/). Along the way, literally
+dozens of individuals have contributed code, designs, ideas, and management
+across multiple teams. Combine this with the fact that the work product is all
+in the public domain and it becomes clear that the project has no single
+"owner". Defining direction in this environment is inherently challenging, so
+we take a pragmatic approach. 
+
+Day-to-day changes (largely backwards-compatible changes) should be
+reviewed by a second set of eyes before merging, but can be merged by anyone
+in the `eregs` organization. However, to keep the project moving forward, we
+allow the original submitter to merge their own submissions after one week if
+there is no dissent.
+
+Larger policy changes and major code shifts warrant additional input from
+affected parties. Therefore, such changes should be open for discussion (as an
+issue in the eregs.github.io repository) for a minimum of two weeks. During
+this time, anyone in the `eregs` organization can _veto_ these changes; this
+is a bit of a nuclear option, so we try to avoid it in favor of constructive
+dialog. 
+
+We defer defining exactly what "major" and "day-to-day" changes are and how to
+avoid deadlock in veto scenarios until the need arises. We use our best
+judgement.
+
+In summary:
+
+* Day-to-day changes can be merged by anyone in the org
+* Day-to-day changes should not be merged by the submitter unless 1 week has
+    passed
+* Policy changes should be open for discussion for at least 2 weeks
+* Policy changes can be vetoed by any org member