WIP: add contributor policies and update related documentation

CONTRIBUTING.md

@@ -8,10 +8,9 @@ many important organizations!
 * We generally hang out in the [Progressive Coder Network slack](https://www.progcode.org/) in the `#spoke` channel
   * Please fill out the Join form there, and once you are on-boarded, we can chat live!
   * ProgCode has community guidelines
-* Feel free to [create an issue or comment on an existing issue](https://github.com/MoveOnOrg/Spoke/issues) -- Every time we hear from the outside progressive developer community, we do a little dance.
-* We also welcome reaching out on our [MoveOn Spoke interest form](https://act.moveon.org/survey/spoke-project/) with questions, etc.
+* Feel free to [create an issue or comment on an existing issue](https://github.com/spokecommunity/Spoke/issues) -- Every time we hear from the outside progressive developer community, we do a little dance.
 
-In all forums we affirm the [Progressive Coder Community Guidelines](https://docs.google.com/document/d/1coMHvuGf6x6Qn_73SEhOXi_QaoRBM__3Zj6_5TyrmWs/edit#heading=h.ab96v3qhdgk9)
+Our [contributor Code of Conduct](./code-of-conduct.md) is based on the [Contributor Covenant](https://www.contributor-covenant.org/) and governs all interactions between contributors and potential contributors. Please read it and let us know if you have questions or want to report a violation. We take reports seriously and will never retaliate against someone for reporting.
 
 We are a community of campaigns, staffed organizations, and
 volunteers. We affirm our love and support for our volunteers and
@@ -25,11 +24,11 @@ gratitude and appreciation of everyone's time and work.
 Generally, the first steps are:
 
 * Fork this repository and clone it locally. Note that unlike the git default, our main branch is called `main`.
-* Get a working development environment (see the [README](https://github.com/MoveOnOrg/Spoke/#spoke) and [docs/](https://github.com/MoveOnOrg/Spoke/tree/main/docs))-- reach out through our communication channels (above) if you have issues.
+* Get a working development environment (see the [README](https://github.com/spokecommunity/Spoke/#spoke) and [docs/](https://github.com/spokecommunity/Spoke/tree/main/docs))-- reach out through our communication channels (above) if you have issues.
 
 ### Picking an issue
 
-* We mark issues that are good first issues with the [`good first issue` tag](https://github.com/MoveOnOrg/Spoke/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22). Most of these are marked `easy`, but if you are a more experienced developer then some are not but it may be *easy for you*!
+* We mark issues that are good first issues with the [`good first issue` tag](https://github.com/spokecommunity/Spoke/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22). Most of these are marked `easy`, but if you are a more experienced developer then some are not but it may be *easy for you*!
 * Comment on the issue and tell us that you're working on it.
 * If you have an idea, then create an issue and if possible discuss with us on slack (see communication channels). If it's a big project, we might try to arrange a call or video chat to make sure we're all on the same page.
 * If you reach out to us, on github or slack we'll generally try to respond within 1 business day.  If you haven't heard from us, please ping us again.
@@ -44,37 +43,7 @@ Generally, the first steps are:
 
 ### Submitting your Pull Request
 
-* Push your changes to your forked version, and create a Pull Request on GitHub for your change
+* Push your changes to your forked version (or to a new branch on this repo if you're a maintainer), and create a Pull Request on GitHub for your change
 * In the description or title of the pull request, include a reference to the issue that the pull request relates to
 * If you are a junior developer, please don't be concerned about the code quality -- we will work with you if there are issues. We are super-excited to help junior developers submit and merge a first pull request.  If you have done some work and tests aren't passing, you can still feel free to submit it, and just comment on the issue that you are having trouble, and we'll work together to fix it.
-* Pull Requests sometimes take a bit of time to review or comment on. We will try to respond within 1-3 business days (sometimes we are busy fighting the good fight!)
-
-### Release Process
-
-This describes MoveOn's internal regression testing and release process, and can be used as an example of how another organization could set up a release process for Spoke.
-
-As an organization starts using complex software at scale, it becomes increasingly important to avoid production outages and scaling issues when possible. As MoveOn transitioned into a production software development stage with Spoke, instead of just rolling out changes when they became ready, we decided to adopt a more formal and careful process.
-
-We're a small team, practice agile software development, and plan weekly sprints starting every Monday. For us, it makes sense to do weekly releases of production software. We deploy changes every Wednesday afternoon.
-
-The actual process:
-* On Tuesday, we delete the old stage-main branch, and cut a new one from main: 
-  * git checkout main
-  * git branch -D stage-main
-  * git push origin :stage-main
-  * git checkout -b stage-main
-  * git push origin stage-main
-* On Tuesday we will test each PR and only merge it to stage-main and NOT main. We wait to merge to main only after Wednesday's regression 'testing party'
-  * This ensures that PRs will not contain anything that breaks deployment and also will allow us to see if any PRs negatively interact with each other before they end up merged to main.  Why bother with this step? it's helpful to have a separate "release candidate" on the stage-main branch because in earlier testing rounds people weren't sure what had been deployed to staging and having a separate branch makes this explicit and clear.
-  * When you have tested a PR branch locally and approve its merge (you do NOT click the 'merge' button in github -- that would merge to main (BAD!)). Instead:
-  * if this is a different person that created stage-main above, they should run:
-    * git fetch
-    * git checkout stage-main
-    * git reset --hard origin/stage-main
-  * Then deploy the stage-main branch to our staging environment
-* By EOD Tuesday, we should have reviewed and merged the PRs to stage-main that contain changes we would like to test on staging and roll to prod Wednesday.
-* On Wednesday morning, the whole team then piles onto regression testing staging
-* After the tech team tests staging, we get at least one member of the Mobile team to signoff on the state of staging.
-* If we fix all issues, regression test staging, and tech and mobile have signed off on staging, we merge stage-main back into main, roll to prod, as early as signoff is possible and at latest Thursday morning. This way, we know that the main branch is stable and is what we're running in our prod env.
-* After we roll to prod, at least one member of the Tech and Mobile team verify that prod is up and working.
-* We never roll code directly to prod without first testing on staging.
+* We will try to respond within 1-3 business days.

README.md

@@ -9,6 +9,28 @@ Spoke was created by Saikat Chakrabarti and Sheena Pakanati, and is now maintain
 
 The latest version is [1.4.1](https://github.com/MoveOnOrg/Spoke/tree/v1.4.1) (see [release notes](https://github.com/MoveOnOrg/Spoke/blob/main/docs/RELEASE_NOTES.md#v141)) which we recommend for production use, while our `main` branch is where features still in development and testing will be available.
 
+# Contributing
+
+We welcome contributions from progressive developers of all skill levels. Please see our [contributor guidelines](./CONTRIBUTING.md) for information on how to get started.
+
+## Maintainers
+
+We follow a modified version of the [Moya contributor protocol](https://github.com/Moya/contributors). Specifically:
+
+1) Anyone with a merged PR is eligible to become a maintainer.
+2) PRs are eligible for merge when two existing maintainers approve them.
+3) Nobody, including maintainers, can push directly to `main`. Everyone follows the same rules and goes through the same code review process.
+
+You can see the maintainers team membership [here](https://github.com/orgs/spokecommunity/teams/maintainers).
+
+## Core team
+
+The core team is made up of maintainers who have worked on the project for a longer period of time. They have admin privileges on this repository, but aside from that, they're just regular maintainers. They have no special committing or review privileges. The core team is also the first point of contact for [code of conduct](./code-of-conduct.md) violation reports. The core team currently comprises:
+- [Ben Chrobot](https://github.com/bchrobot)
+- [Harpo Jaeger](https://github.com/harpojaeger)
+
+Please reach out to either or both of them with any questions or to report a Code of Conduct violation.
+
 ## Note
 
 This is generated from [react-apollo-starter-kit](https://github.com/saikat/react-apollo-starter-kit).  Look at that project's README for info on some of the libraries used.

code-of-conduct.md

@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting [the core team](./README.md#core-team). All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq