Fix typos.

checklists/managing-pull-requests.md

@@ -1,6 +1,6 @@
 # Managing Pull Requests
 
-* Respond within the commited response time maximum
+* Respond within the committed response time maximum
 * Questions to ask when reviewing:
   * Does the PR add value?
     * Does it fix an existing issue?

communication/saying-no.md

@@ -74,7 +74,7 @@ Thank you again for filing this, however, we greatly appreciate your interest in
 Thanks for providing your input. Your idea sounds interesting to us but we currently do not have the resources to investigate further. We would, however, welcome a contribution implementing this idea. Are you interested in contributing this?
 ```
 
-### Pull Reqests
+### Pull Requests
 
 **Contributor has not responded to review**
 
@@ -84,7 +84,7 @@ Like GitHub issues, occasionally when we review pull requests and request change
 Thank you for submitting this pull request!
 
 We've requested some changes to this pull request on code review
-and cannot re-review it until we receive a response. We haven't recieved
+and cannot re-review it until we receive a response. We haven't received
 a response yet - though we understand there are many reasons for this,
 especially if you are contributing on your own time - and cannot move
 forward until we do, so we are closing this pull request for now.
@@ -95,7 +95,7 @@ in the future, please feel free to re-open it and we will review it then.
 
 **Pull Request is not right for the project at this time**
 
-Sometimes a pull request will take a project in a direction that the owners do not wish it to, or add something to the project before the project is ready to take on the responsibilty of maintaining it. These are some of the most difficult cases to deal with, but again it's crucial to acknowledge the effort that went into the pull request when saying no - it's also crucial to show empathy and respect not just for the person who opened the pull request but also for the person's work.
+Sometimes a pull request will take a project in a direction that the owners do not wish it to, or add something to the project before the project is ready to take on the responsibility of maintaining it. These are some of the most difficult cases to deal with, but again it's crucial to acknowledge the effort that went into the pull request when saying no - it's also crucial to show empathy and respect not just for the person who opened the pull request but also for the person's work.
 
 ```
 Thank you for submitting this pull request!
@@ -117,4 +117,4 @@ This may be done when conversation on an issue or pull request becomes unproduct
 
 ### Older Issues/Pull Requests
 
-Some Chef Open Source projects may choose to lock conversation on issues or pull requests that are beyond a certain age (for example, one year). Whether or not to do this is up to the Project Owners. If someone wishes to re-open conversation around an old issue or pull request that has been locked, they should create a new one and link to the old issue or pull request. This ensures that issues/pull requests - even when they resurface after a long time - are all written within current context. This also avoids massive merge conflicts in the case of aged pull requests.
+Some Chef Open Source projects may choose to lock conversation on issues or pull requests that are beyond a certain age (for example, one year). Whether or not to do this is up to the Project Owners. If someone wishes to re-open conversation around an old issue or pull request that has been locked, they should create a new one and link to the old issue or pull request. This ensures that issues/pull requests - even when they resurface after a long time - are all written within current context. This also avoids massive merge conflicts in the case of aged pull requests.

projects/chef-automate.md

@@ -1,7 +1,7 @@
 # Chef Automate Project
 
 The Chef Automate project includes Chef Automate and all related
-deployment toplogies supported by `chef-automate deploy`.
+deployment topologies supported by `chef-automate deploy`.
 
 **Slack Channel** #automate-dev
 

repo-management/project-required-setup.md

@@ -59,7 +59,7 @@ GitHub displays the Code of Conduct file when a user opens a new PR or Issue. We
 
 ### TEAMS.md
 
-The `TEAMS.md` file defines the team responsible for the project repository. This file should exist in the base of the GitHub repository and include a link back to team document in *this* repository. The specific details of the team will be stored in the [central teams directory](../teams) of this repository so that we don't need to replicate information accross multiple repositories.
+The `TEAMS.md` file defines the team responsible for the project repository. This file should exist in the base of the GitHub repository and include a link back to team document in *this* repository. The specific details of the team will be stored in the [central teams directory](../teams) of this repository so that we don't need to replicate information across multiple repositories.
 
 ### .github/CODEOWNERS