Stage main

CONTRIBUTING.md

@@ -15,7 +15,7 @@ many important organizations!
 Generally, the first steps are:
 
 * Fork this repository and clone it locally
-* Get a working development environment (see the [README](https://github.com/MoveOnOrg/Spoke/#spoke) and [docs/](https://github.com/MoveOnOrg/Spoke/tree/master/docs))-- reach out through our communication channels (above) if you have issues.
+* 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.
 
 ### Picking an issue
 
@@ -41,30 +41,30 @@ Generally, the first steps are:
 
 ### 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. 
+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. 
+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-master branch, and cut a new one from master: 
-  * git checkout master
-  * git branch -D stage-master
-  * git push origin :stage-master
-  * git checkout -b stage-master
-  * git push origin stage-master
-* On Tuesday we will test each PR and only merge it to stage-master and NOT master. We wait to merge to master 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 master.  Why bother with this step? it's helpful to have a separate "release candidate" on the stage-master 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 master (BAD!)). Instead:
-  * if this is a different person that created stage-master above, they should run:
+* 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-master
-    * git reset --hard origin/stage-master
-  * Then deploy the stage-master branch to our staging environment
-* By EOD Tuesday, we should have reviewed and merged the PRs to stage-master that contain changes we would like to test on staging and roll to prod Wednesday.
+    * 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-master back into master, roll to prod, as early as signoff is possible and at latest Thursday morning. This way, we know that the master branch is stable and is what we're running in our prod env.
+* 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.

README.md

@@ -6,15 +6,15 @@ Spoke is an open source text-distribution tool for organizations to mobilize sup
 
 Spoke was created by Saikat Chakrabarti and Sheena Pakanati, and is now maintained by MoveOn.org.
 
-The latest version is [1.1.0](https://github.com/MoveOnOrg/Spoke/tree/v1.1) (see [release notes](https://github.com/MoveOnOrg/Spoke/blob/master/docs/RELEASE_NOTES.md#v11)) which we recommend for production use, while our `master` branch is where features still in development and testing will be available.
+The latest version is [1.2.0](https://github.com/MoveOnOrg/Spoke/tree/v1.2) (see [release notes](https://github.com/MoveOnOrg/Spoke/blob/master/docs/RELEASE_NOTES.md#v12)) which we recommend for production use, while our `master` branch is where features still in development and testing will be available.
 
 ## 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.
 
 ## Deploy to Heroku
 
-<a href="https://heroku.com/deploy?template=https://github.com/MoveOnOrg/Spoke">
+<a href="https://heroku.com/deploy?template=https://github.com/MoveOnOrg/Spoke/tree/v1.2">
   <img src="https://www.herokucdn.com/deploy/button.svg" alt="Deploy">
 </a>
 

docs/HOWTO_HEROKU_DEPLOY.md

@@ -32,7 +32,7 @@
 
 
 ## Notes about Twilio environment variable setup
-If you need to use Twilio in development but with live keys, click [here](https://github.com/MoveOnOrg/Spoke/blob/master/docs/HOWTO_INTEGRATE_TWILIO.md) for instructions.
+If you need to use Twilio in development but with live keys, click [here](https://github.com/MoveOnOrg/Spoke/blob/main/docs/HOWTO_INTEGRATE_TWILIO.md) for instructions.
 
 Visit [here](https://www.twilio.com/docs/api/messaging/services-and-copilot) to configure messaging service features
 

docs/RELEASE_NOTES.md

@@ -1,5 +1,24 @@
 # Release Notes
 
+## v1.2
+
+Version 1.2 is our second release since MoveOn has adopted Spoke. We are committed to fixing bugs, adding new features and making this project as nimble as possible. For this release, we've included changes from [GetUp](https://www.getup.org.au/), updated certain dependencies, updated Auth0 integration, added user editing capabilities for texters and admins, added the ability to revisit previous conversations and continued to add outside integration points with outside CRMs. Please continue to add and work on our growing [issues list](https://github.com/MoveOnOrg/Spoke/issues). We have also switched from `master` => `main` as a new naming convention for the most stable branch.
+
+We've worked on a lot, but some critical developments to highlight include:
+* Adds dynamic assignment functionality for texters
+* Adds user editing capabilities for texters and administrators
+* Adds the ability to revisit previous conversations
+* Adds support for customized styling for campaigns
+* Adds ActionKit integration for event sign up and documentation
+* Adds support for multi-media images in outgoing texts (mms)
+* Adds support for campaign script editing on live campaigns
+* Moved to Prop-Types library, upgraded Webpack and other development dependencies
+* Adds Code Climate test integration to monitor test coverage
+* Adds opt out count for a campaign to admin dashboard stats
+* Adds free Heroku deployment setup
+
+Thanks go to to all our contributors for this release including: [jmcarp](https://github.com/jmcarp), [hiemanshu](https://github.com/hiemanshu), [lperson](https://github.com/lperson), [jamesr2323](https://github.com/jamesr2323), [benmort](https://github.com/benmort), [ben-pr-p](https://github.com/ben-pr-p), [lady3bean](https://github.com/lady3bean), [schuyler1d](https://github.com/schuyler1d), [shakalee14](https://github.com/shakalee14), [sreynen](https://github.com/sreynen), [mathemagica](https://github.com/mathemagica)
+
 ## v1.1
 
 Version 1.1 is our first release since MoveOn has been using Spoke successfully in production. We are committed to
@@ -14,8 +33,9 @@ highlights for this release:
 * Resolves many bugs related to saving and updating a Campaign for admins
 * Improves the Texter interface (better reply visibility, especially on mobile) along with sending on `<Enter>`
 * Adds a [Deploy to Heroku](https://github.com/MoveOnOrg/Spoke#deploy-to-heroku) button for easier first-time deployments
-* Documented [how to deploy on Amazon AWS Lambda](https://github.com/MoveOnOrg/Spoke/blob/master/docs/DEPLOYING_AWS_LAMBDA.md)
+* Documented [how to deploy on Amazon AWS Lambda](https://github.com/MoveOnOrg/Spoke/blob/main/docs/DEPLOYING_AWS_LAMBDA.md)
 * Migrated from a RethinkDB backend to a Knex.js backend (we recommend use with postgresql database)
 * Improved Spoke's security
 
-Thanks go to to all our contributors including: [anasauce](https://github.com/anasauce), [hiemanshu](https://github.com/hiemanshu), [mathemagica](https://github.com/mathemagica), [sandramchung](https://github.com/sandramchung), [schuyler1d](https://github.com/schuyler1d), [shakalee14](https://github.com/shakalee14), [sreynen](https://github.com/sreynen)!
+
+Thanks go to to all our contributors including: [anasauce](https://github.com/anasauce), [hiemanshu](https://github.com/hiemanshu), [mathemagica](https://github.com/mathemagica), [sandramchung](https://github.com/sandramchung), [schuyler1d](https://github.com/schuyler1d), [shakalee14](https://github.com/shakalee14), [sreynen](https://github.com/sreynen)

package.json

@@ -1,6 +1,6 @@
 {
   "name": "spoke",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "description": "Spoke",
   "main": "src/server",
   "engines": {