Merge pull request #1408 from cisagov/typo-fixes

Typo fixes

docs/architecture/decisions/0024-production-release-cadence.md

@@ -15,9 +15,9 @@ Going into our first production launch we need a plan describing what our releas
 **Option 1:** Releasing to stable/staging once a sprint
 Releasing once a sprint would mean that we release the past sprint's work to stable at the end of the current sprint. At the same point, the current sprint's work would be pushed to staging, thus making staging a full sprint ahead of stable. While this is more straight forward, it means our users would have to wait longer to see changes that weren't deemed critical.
 **Option 2:** Releasing to stable/staging once a week
-Releasing once a week would follow the same flow but with code being released to staging one week before the same code is released to stable. This would make stable only one week behind staging and would allow us to roll out minor bug fixes and faster with greater speed. The negative side is that we have less time to see if errors occur on staging
+Releasing once a week would follow the same flow but with code being released to staging one week before the same code is released to stable. This would make stable only one week behind staging and would allow us to roll out minor bug fixes faster. The negative side is that we have less time to see if errors occur on staging.
 
-In both of the above scenarios the release date would fall on the same day of the week that the sprint starts, which is currently a Wednesday. Additionally, in both scenarios the release commits would eventually be tagged with both a staging and stable tag. Furthermore, critical bugs or features would be exempt from these restrictions based on the product owner's discretion.
+In both of the above scenarios, the release date would fall on the same day of the week that the sprint starts which is currently a Wednesday. Additionally, in both scenarios the release commits would eventually be tagged with both a staging and stable tag. Furthermore, critical bugs or features would be exempt from these restrictions based on the product owner's discretion.
 
 ## Decision
 
@@ -25,6 +25,6 @@ We decided to go with option 2 and release once a week once in production. This
 
 ## Consequences
 
-Work not completed by end of the sprint will have to wait to be added to stable. Also, making quick fixes for bugs that are found on stable will be a little more complicated to fix.
+Work not completed by end of the sprint will have to wait to be added to stable. Also, making quick fixes for bugs that are found on stable will be a little more complicated.
 
 When first going into production, staging and stable will start with the same code base. The following week a new release will be made to staging, but not stable as no code will have been on staging long enough to warrant another release. Thus just at the start of launch stable will be essentially frozen for 2 weeks, not one.

docs/django-admin/roles.md

@@ -19,7 +19,7 @@ To do this, do the following:
 3. Click on their username, then scroll down to the `User Permissions` section.
 4. Under `User Permissions`, see the `Groups` table which has a column for `Available groups` and `Chosen groups`. Select the permission you want from the `Available groups` column and click the right arrow to move it to the  `Chosen groups`. Note, if you want this user to be an analyst select `cisa_analysts_group`, otherwise select the `full_access_group`.
 5. (Optional) If the user needs access to django admin (such as an analyst), then you will also need to make sure "Staff Status" is checked. This can be found in the same `User Permissions` section right below the checkbox for `Active`.
-6. Click `Save` to apply all changes
+6. Click `Save` to apply all changes.
 
 ## Removing a user group permission via django-admin
 
@@ -30,7 +30,7 @@ If an employee was given the wrong permissions or has had a change in roles that
 3. In this table, select the permission you want to remove from the `Chosen groups` and then click the left facing arrow to move the permission to `Available groups`.
 4. Depending on the scenario you may now need to add the opposite permission group to the `Chosen groups` section, please see the section above for instructions on how to do that.
 5. If the user should no longer see the admin page, you must ensure that under `User Permissions`, `Staff status` is NOT checked.
-6. Click `Save` to apply all changes
+6. Click `Save` to apply all changes.
 
 ## Editing group permissions through code
 
@@ -40,4 +40,4 @@ We can edit and deploy new group permissions by:
 2. Duplicating migration `0036_create_groups_01`
 and running migrations (append the name with a version number
 to help django detect the migration eg 0037_create_groups_02)
-3. Making sure to update the dependency on the new migration with the previous migration
+3. Making sure to update the dependency on the new migration with the previous migration.

docs/operations/README.md

@@ -55,9 +55,9 @@ In the case where a bug fix or feature needs to be added outside of the normal c
 
 1. Code will need to be branched NOT off of main, but off of the same commit as the most recent stable commit. This should be the one tagged with the most recent vX.XX.XX value.
 2. After making the bug fix, the approved PR branch will not be merged yet, instead it will be tagged with a new release tag, incrementing the patch value from the last commit number.
-3. If main and stable are on the the same commit then merge this branch into the staging using the staging release tag (staging-<the hotfix release number>). 
+3. If main and stable are on the the same commit then merge this branch into staging using the staging release tag (staging-<the hotfix release number>). 
 4. If staging is already ahead stable, you may need to create another branch that is based off of the current staging commit, merge in your code change and then tag that branch with the staging release.
-5. Wait to merge your original branch until both deploys finish.  Once they succeed then merge to main per the usual process.
+5. Wait to merge your original branch until both deploys finish. Once they succeed then merge to main per the usual process.
 
 ## Serving static assets
 We are using [WhiteNoise](http://whitenoise.evans.io/en/stable/index.html) plugin to serve our static assets on cloud.gov. This plugin is added to the `MIDDLEWARE` list in our apps `settings.py`.

docs/operations/runbooks/rotate_application_secrets.md

@@ -112,7 +112,7 @@ base64 -i client.key
 base64 -i client.crt
 ```
 
-You'll need to give the new certificate to the registry vendor _before_ rotating it in production. Once it has been accepted by the vender, make sure to update the kdbx file on Google Drive.
+You'll need to give the new certificate to the registry vendor _before_ rotating it in production. Once it has been accepted by the vendor, make sure to update the kdbx file on Google Drive.
 
 ## REGISTRY_HOSTNAME
 

docs/operations/runbooks/update_python_dependencies.md

@@ -3,7 +3,7 @@
 
 1. Check the [Pipfile](../../../src/Pipfile) for pinned dependencies and manually adjust the version numbers
 
-1. Run
+2. Run
 
         cd src
         docker-compose run app bash -c "pipenv lock && pipenv requirements > requirements.txt"
@@ -14,6 +14,6 @@
 
     The requirements.txt is used by Cloud.gov. It is needed to work around a bug in the CloudFoundry buildpack version of Pipenv that breaks on installing from a git repository.
 
-1. (optional) Run `docker-compose stop` and `docker-compose build` to build a new image for local development with the updated dependencies.
+3. (optional) Run `docker-compose stop` and `docker-compose build` to build a new image for local development with the updated dependencies.
 
     The reason for de-coupling the `build` and `lock` steps is to increase consistency between builds--a run of `build` will always get exactly the dependencies listed in `Pipfile.lock`, nothing more, nothing less.