more minor 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/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.