diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index bb7c9efe3a1ee..41ee9af1e7402 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -90,7 +90,7 @@ maximize the chances of your PR being merged.
 * We expect that once a PR is opened, it will be actively worked on until it is merged or closed.
   We reserve the right to close PRs that are not making progress. This is generally defined as no
   changes for 7 days. Obviously PRs that are closed due to lack of activity can be reopened later.
-  Closing stale PRs helps us keep on top of all of the work currently in flight.
+  Closing stale PRs helps us to keep on top of all of the work currently in flight.
 * If a commit deprecates a feature, the commit message must mention what has been deprecated.
   Additionally, [DEPRECATED.md](DEPRECATED.md) must be updated as part of the commit.
 * Please consider joining the [envoy-dev](https://groups.google.com/forum/#!forum/envoy-dev)
diff --git a/REPO_LAYOUT.md b/REPO_LAYOUT.md
index bc2bb7660a810..cd87e015ac5b8 100644
--- a/REPO_LAYOUT.md
+++ b/REPO_LAYOUT.md
@@ -28,7 +28,7 @@ are:
 ## [source/](source/)
 
 * [common/](source/common/): Core Envoy code (not specific to extensions) that is also not
-  specific to a standalone server implementation. I.e., this is code that could be used if Envoy
+  specific to a standalone server implementation. I.e., this is the code that could be used if Envoy
   were eventually embedded as a library.
 * [docs/](source/docs/): Miscellaneous developer/design documentation that is not relevant for
   the public user documentation.
diff --git a/SECURITY_RELEASE_PROCESS.md b/SECURITY_RELEASE_PROCESS.md
index ca8d16e276781..ac49c34c04745 100644
--- a/SECURITY_RELEASE_PROCESS.md
+++ b/SECURITY_RELEASE_PROCESS.md
@@ -1,7 +1,7 @@
 # Security Release Process
 
 Envoy is a large growing community of volunteers, users, and vendors. The Envoy community has
-adopted this security disclosures and response policy to ensure we responsibly handle critical
+adopted this security disclosure and response policy to ensure we responsibly handle critical
 issues.
 
 ## Product Security Team (PST)
@@ -73,7 +73,7 @@ These steps should be completed within the 1-7 days of Disclosure.
 - The Fix Lead and the Fix Team will create a
   [CVSS](https://www.first.org/cvss/specification-document) using the [CVSS
   Calculator](https://www.first.org/cvss/calculator/3.0). The Fix Lead makes the final call on the
-  calculated CVSS; it is better to move quickly than make the CVSS perfect.
+  calculated CVSS; it is better to move quickly than making the CVSS perfect.
 - The Fix Team will notify the Fix Lead that work on the fix branch is complete once there are LGTMs
   on all commits in the private repo from one or more maintainers.
 
@@ -160,7 +160,7 @@ said issue, they must agree to the same terms and only find out information on a
 
 In the unfortunate event you share the information beyond what is allowed by this policy, you _must_
 urgently inform the envoy-security@googlegroups.com mailing list of exactly what information leaked
-and to whom. A retrospective will take place after the leak so we can assess how to not make the
+and to whom. A retrospective will take place after the leak so we can assess how to prevent making the
 same mistake in the future.
 
 If you continue to leak information and break the policy outlined here, you will be removed from the
diff --git a/STYLE.md b/STYLE.md
index 2b641607e23de..72a5411ae48cb 100644
--- a/STYLE.md
+++ b/STYLE.md
@@ -1,6 +1,6 @@
 # C++ coding style
 
-* The Envoy source code is formatted using clang-format. Thus all white space, etc.
+* The Envoy source code is formatted using clang-format. Thus all white spaces, etc.
   issues are taken care of automatically. The Travis tests will automatically check
   the code format and fail. There are make targets that can both check the format
   (check_format) as well as fix the code format for you (fix_format).
@@ -96,7 +96,7 @@ A few general notes on our error handling philosophy:
   silently be ignored and should crash the process either via the C++ allocation error exception, an
   explicit `RELEASE_ASSERT` following a third party library call, or an obvious crash on a subsequent
   line via null pointer dereference. This rule is again based on the philosophy that the engineering
-  costs of properly handling these cases is not worth it. Time is better spent designing proper system
+  costs of properly handling these cases are not worth it. Time is better spent designing proper system
   controls that shed load if resource usage becomes too high, etc.
 * The "less is more" error handling philosophy described in the previous two points is primarily
   based on the fact that restarts are designed to be fast, reliable and cheap.