Move out governance out to its own section

GOVERNANCE.md

@@ -0,0 +1,59 @@
+**This is all hypothetical and subject to change. This document is only really
+relevant if Zelm gets enough adoption to actually require a governance structure**.
+
+In light of Zelm's tightly scoped technical goals as well as the current state
+of Elm's community, Zelm's social dynamics will look different from Elm's.
+
+In particular Elm's community is:
+
++ Stable: the number of Elm veterans in the community outnumbers the number of
+  new Elm developers.
++ Relatively consistent when it comes to opinions about what Elm code should
+  look like: 
+
+**And as a reminder Zelm does not intend (at least not until 2025) to do feature
+development on the Elm language itself or any expansionary feature development
+on the Elm compiler.**
+
+This mean that Zelm does not really need a visionary at its helm or large
+amounts of time and energy spent on groundbreaking features. What Zelm needs
+instead foremost is a low, but consistent, amount of attention to accept PRs and
+bug reports from the community. Secondarily, as time allows, Zelm will slowly
+grind through bugs that have no PRs.
+
+The absence of a need for radical design or commitment and instead a focus on a
+consistent source of low amounts of energy makes Zelm a good fit for committee
+leadership rather than individual leadership.
+
+As such Zelm hopes to
+
++ Maintain at least five active members of the `zelm` and `zelm-explorations`
+  GitHub organizations who have push/merge permissions across the repositories
+  managed by those organizations. Potentially more than five, but ideally
+  remaining at some odd number to allow for tie breaks in the (hopefully rare)
+  case of controversial decisions.
++ Regularly rotate out any inactive members (people who do not feel they can
+  engage more than once a week) for active members.
+
+**These are hopes not commitments.** But I do consider them valid barometers of
+whether Zelm has a project has succeeded.
+
+Because Zelm does not intend (at least not until 2025) to do feature
+development on the Elm language itself, Zelm makes a different set of social
+trade-offs compared to Elm itself.
+
+Concretely, Zelm hopes to achieve timely (< 1 week) responses to issues and PRs
+that fit within Zelm's mission scope, i.e. bug fixes to foundational packages or
+to the compiler. These should be fixes with very few or no questions of design
+and no changes to any APIs.
+
+**Note that responses do not necessarily mean that issues will be fixed or PRs
+will be merged**. Again, because of how tightly scoped Zelm's technical mission
+is, it is likely that many issues and PRs will lie outside what Zelm intends to
+address at least until 2025. Even if the issue or PR lies within Zelm's scope,
+it may either be tricky to fit or to merge in.
+
+However, even if you don't get your issue fixed or merged into a Zelm
+repository, Zelm gives you the tools through custom repositories and package
+overrides to do a lot of this on your own!
+

README.md

@@ -366,63 +366,9 @@ this is just to bundle it up as a zipfile, throw it up somewhere, and then
 expose that location as a new entry under `single-package-locations` in your
 `custom-package-repository-config.json` file in `$ELM_HOME/0.19.1/zelm`.
 
-# Social Dynamics
-
-In light of Zelm's tightly scoped technical goals as well as the current state
-of Elm's community, Zelm's social dynamics will look different from Elm's.
-
-In particular Elm's community is:
-
-+ Stable: the number of Elm veterans in the community outnumbers the number of
-  new Elm developers.
-+ Relatively consistent when it comes to opinions about what Elm code should
-  look like: 
-
-**And as a reminder Zelm does not intend (at least not until 2025) to do feature
-development on the Elm language itself or any expansionary feature development
-on the Elm compiler.**
-
-This mean that Zelm does not really need a visionary at its helm or large
-amounts of time and energy spent on groundbreaking features. What Zelm needs
-instead foremost is a low, but consistent, amount of attention to accept PRs and
-bug reports from the community. Secondarily, as time allows, Zelm will slowly
-grind through bugs that have no PRs.
-
-The absence of a need for radical design or commitment and instead a focus on a
-consistent source of low amounts of energy makes Zelm a good fit for committee
-leadership rather than individual leadership.
-
-As such Zelm hopes to
-
-+ Maintain at least five active members of the `zelm` and `zelm-explorations`
-  GitHub organizations who have push/merge permissions across the repositories
-  managed by those organizations. Potentially more than five, but ideally
-  remaining at some odd number to allow for tie breaks in the (hopefully rare)
-  case of controversial decisions.
-+ Regularly rotate out any inactive members (people who do not feel they can
-  engage more than once a week) for active members.
-
-**These are hopes not commitments.** But I do consider them valid barometers of
-whether Zelm has a project has succeeded.
-
-Because Zelm does not intend (at least not until 2025) to do feature
-development on the Elm language itself, Zelm makes a different set of social
-trade-offs compared to Elm itself.
-
-Concretely, Zelm hopes to achieve timely (< 1 week) responses to issues and PRs
-that fit within Zelm's mission scope, i.e. bug fixes to foundational packages or
-to the compiler. These should be fixes with very few or no questions of design
-and no changes to any APIs.
-
-**Note that responses do not necessarily mean that issues will be fixed or PRs
-will be merged**. Again, because of how tightly scoped Zelm's technical mission
-is, it is likely that many issues and PRs will lie outside what Zelm intends to
-address at least until 2025. Even if the issue or PR lies within Zelm's scope,
-it may either be tricky to fit or to merge in.
-
-However, even if you don't get your issue fixed or merged into a Zelm
-repository, Zelm gives you the tools through custom repositories and package
-overrides to do a lot of this on your own!
+# Governance Structure
+
+See [./GOVERNANCE.md](./GOVERNANCE.md)
 
 # Design Choices Reasoning