diff --git a/examples/scope-hoisting/README.md b/examples/scope-hoisting/README.md
index d84d0721197..6bf03433229 100644
--- a/examples/scope-hoisting/README.md
+++ b/examples/scope-hoisting/README.md
@@ -4,17 +4,17 @@ This is the dependency graph for the example: (solid lines express sync imports,
 
 ![](graph.png)
 
-All modules except `cjs` are EcmaScript modules. `cjs` is a CommonJs module.
+All modules except `cjs` are EcmaScript modules. `cjs` is a CommonJS module.
 
-The interesting thing here is that putting all modules in single scope won't work, because of multiple reasons:
+The interesting thing here is that putting all modules in a single scope won't work, because of multiple reasons:
 
 - Modules `lazy`, `c`, `d` and `cjs` need to be in a separate chunk
 - Module `shared` is accessed by two chunks (different scopes)
-- Module `cjs` is a CommonJs module
+- Module `cjs` is a CommonJS module
 
 ![](graph2.png)
 
-webpack therefore uses a approach called **"Partial Scope Hoisting"** or "Module concatenation", which chooses the largest possible subsets of ES modules which can be scope hoisted and combines them with the default webpack primitives.
+Webpack, therefore, uses an approach called **"Partial Scope Hoisting"** or "Module concatenation", which chooses the largest possible subsets of ES modules which can be scope hoisted and combines them with the default webpack primitives.
 
 ![](graph3.png)
 
diff --git a/examples/scope-hoisting/template.md b/examples/scope-hoisting/template.md
index 7cb3b37bc4c..601a518e47c 100644
--- a/examples/scope-hoisting/template.md
+++ b/examples/scope-hoisting/template.md
@@ -4,9 +4,9 @@ This is the dependency graph for the example: (solid lines express sync imports,
 
 ![](graph.png)
 
-All modules except `cjs` are EcmaScript modules. `cjs` is a CommonJs module.
+All modules except `cjs` are EcmaScript modules. `cjs` is a CommonJS module.
 
-The interesting thing here is that putting all modules in single scope won't work, because of multiple reasons:
+The interesting thing here is that putting all modules in a single scope won't work, because of multiple reasons:
 
 - Modules `lazy`, `c`, `d` and `cjs` need to be in a separate chunk
 - Module `shared` is accessed by two chunks (different scopes)
@@ -14,7 +14,7 @@ The interesting thing here is that putting all modules in single scope won't wor
 
 ![](graph2.png)
 
-webpack therefore uses a approach called **"Partial Scope Hoisting"** or "Module concatenation", which chooses the largest possible subsets of ES modules which can be scope hoisted and combines them with the default webpack primitives.
+Webpack, therefore, uses a approach called **"Partial Scope Hoisting"** or "Module concatenation", which chooses the largest possible subsets of ES modules which can be scope hoisted and combines them with the default webpack primitives.
 
 ![](graph3.png)
 
diff --git a/examples/side-effects/README.md b/examples/side-effects/README.md
index 8eccb8f9e63..e2804cf9c23 100644
--- a/examples/side-effects/README.md
+++ b/examples/side-effects/README.md
@@ -1,4 +1,4 @@
-This example shows how the `sideEffects` flag for library authors works.
+This example shows how the `sideEffects` flag works for library authors.
 
 The example contains a large library, `big-module`. `big-module` contains multiple child modules: `a`, `b` and `c`. The exports from the child modules are re-exported in the entry module (`index.js`) of the library. A consumer uses **some** of the exports, importing them from the library via `import { a, b } from "big-module"`. According to the EcmaScript spec, all child modules _must_ be evaluated because they could contain side effects.
 
diff --git a/examples/side-effects/template.md b/examples/side-effects/template.md
index 258a491cb26..a8ae4f7281c 100644
--- a/examples/side-effects/template.md
+++ b/examples/side-effects/template.md
@@ -1,4 +1,4 @@
-This example shows how the `sideEffects` flag for library authors works.
+This example shows how the `sideEffects` flag works for library authors.
 
 The example contains a large library, `big-module`. `big-module` contains multiple child modules: `a`, `b` and `c`. The exports from the child modules are re-exported in the entry module (`index.js`) of the library. A consumer uses **some** of the exports, importing them from the library via `import { a, b } from "big-module"`. According to the EcmaScript spec, all child modules _must_ be evaluated because they could contain side effects.