Add a governance policy

[cmc333333]

As the eRegs community grows, we have need for more structure. With this
change, I'm proposing an initial governance policy around how changes are
made. It more or less codifies what we've done thus far. Let's follow its
suggestion: we'll leave this PR open for two weeks for discussion. If all is
well, we'll merge at the end.

Ping in particular @ascott1 @tadhg-ohiggins and @jehlers

[porta-antiporta]

For the larger changes (issues that need 2 weeks of discussion) Do we need to provide guidance on necessary considerations that the issue should cover (such as backwards compatibility, or migration strategy in the event of a breaking change). Having these considerations called out would make the 2 week discussion period be more efficient.

[cmc333333]

@porta-antiporta I don't think we'll have a good idea what those considerations will be without making a few such tickets. Maybe we think about specific guidance on how to craft such an issue based on what's been effective in previous instances, after we have several under our belt?

[cmc333333]

@brittag brings up some good ideas:

What about documenting how people can become part of the eregs org?
I’d also be interested in seeing a list there of the orgs/teams that are currently actively involved with eregs (even if it’s just CFPB and 18F)
And where should policy changes be discussed? Do people just discuss them by making an issue or PR on the docs repo? Would be good to note that
you likely already saw this, but Compliance Masonry has been talking about governance, and there’s a good list of questions in this repo from folks: opencontrol/discuss#5
And we’re looking at https://github.com/openopps/openopps-platform/issues/1287 + https://github.com/openopps/openopps-platform/blob/dev/GOVERNANCE.md as a model

[cmc333333]

Kicking the suggested additions to #50 so this can be merged as is.