Address doc typos (#1853)

site/book/01-getting-started/00.md

@@ -1,2 +1,2 @@
 This chapter is a quick introduction to kpt using an example to demonstrate important concepts and
-features. Following chapters will cover these concepts in detail.
+features. The following chapters will cover these concepts in detail.

site/book/01-getting-started/01-system-requirements.md

@@ -1,4 +1,4 @@
-In order to follow along with the examples in this book, the following needs to be installed on you
+In order to follow along with the examples in this book, the following needs to be installed on your
 system:
 
 ## kpt

site/book/03-packages/01-getting-a-package.md

@@ -7,7 +7,7 @@ Let's revisit the Wordpress example:
 $ kpt pkg get https://github.com/GoogleContainerTools/kpt.git/package-examples/wordpress@v0.1
 ```
 
-A package in a Git repo can be fetched by specifying a branch, tag, or a commit SHA. In this case,
+A package in a Git repo can be fetched by specifying a branch, tag, or commit SHA. In this case,
 we are specifying tag `v0.1`.
 
 > Refer to the [command reference][get-doc] for more details.
@@ -56,7 +56,7 @@ The `Kptfile` contains two sections to keep track of the upstream package:
    contains three pieces of information:
    - `repo`: The Git repository where the package can be found
    - `directory`: The directory within the Git repository where this package can be found
-   - `ref`: The Git reference for the package. This can be either a brach, tag, or commit SHA.
+   - `ref`: The Git reference for the package. This can be either a branch, tag, or commit SHA.
 2. The `upstreamLock` section records the upstream Git reference (exact Git SHA) that was fetched by
    kpt. This section is managed by kpt and should not be changed manually.
 
@@ -88,21 +88,22 @@ This is because there are two different package types in kpt:
 In this case, the `mysql` subpackage is a _dependent package_. The upstream package for `mysql` is
 automatically inferred from the parent package. You can think of the `Kptfile` in the `mysql`
 package as implicitly inheriting the `upstream` section of its parent, with the only difference
-being that `upstream.directory` points to `/package-examples/wordpress/mysql`.
+being that `upstream.directory` in the subpackage would instead point to
+`/package-examples/wordpress/mysql`.
 
 ## Package Name and Identifier
 
 It is possible to specify a different local directory name to the `get` command. For example,
-the following fetches the packages to a directory names `mywordpress`:
+the following fetches the packages to a directory named `mywordpress`:
 
 ```shell
 $ kpt pkg get https://github.com/GoogleContainerTools/kpt.git/package-examples/wordpress@v0.1 mywordpress
 ```
 
-The _name_ of a package is given by its directory name. Since the Kptfile is a KRM resource and
+The _name of a package_ is given by its directory name. Since the Kptfile is a KRM resource and
 follows the familiar structure of KRM resources, the name of the package is also available from the
-`metadata.name` field. This must always be the same of the directory name and kpt will update it
-automatically when forking a package. In this case, `metadata.name` is set `mywordpress`.
+`metadata.name` field. This must always be the name of the directory, and kpt will update it
+automatically when forking a package. In this case, `metadata.name` is set to `mywordpress`.
 
 The name of a package is unique within its parent package, but it may not be unique in a deeply
 nested package hierarchy (i.e. Depth > 2). The _unique identifier_ for a package is defined as the

site/book/03-packages/03-editing-a-package.md

@@ -19,27 +19,27 @@ _within_ a package.
 ## Manual edits
 
 As mentioned earlier, you can manually edit or author KRM resources using your favorite editor.
-Since every KRM resource has a known schema, you can take advantage of tooling that assist in
+Since every KRM resource has a known schema, you can take advantage of tooling that assists in
 authoring and validating resource configuration. For example, [Cloud Code] extensions for VS Code
 and IntelliJ provide IDE features such as auto-completion, inline documentation, linting, and snippets.
 
 For example, if you have VS Code installed, try modifying the resources in the `wordpress` package:
 
 ```shell
-$ code wordress
+$ code wordpress
 ```
 
 ## Automation
 
-Often times you want to automate repetitive or complex operations. Having standardized on KRM for
+Oftentimes, you want to automate repetitive or complex operations. Having standardized on KRM for
 all resources in a package (including meta resources) allows us to easily develop automation in
-different toolchains, languages, and at levels of abstraction.
+different toolchains and languages, as well as at levels of abstraction.
 
 For example, setting a label on all the resources in the `wordpress` package can be done
 using the following function:
 
 ```shell
-cd wordpress
+$ cd wordpress
 $ kpt fn eval --image gcr.io/kpt-fn/set-label:v0.1 -- env=dev
 ```
 

site/book/03-packages/06-composing-a-package.md

@@ -53,7 +53,7 @@ $ kpt pkg get https://github.com/kubernetes/website.git/content/en/examples/appl
 
 TODO(#1829): This can be simplified.
 
-This creates a [independent package]. If you wish this to make this a dependent package, you
+This creates an [independent package]. If you wish to make this a dependent package, you
 can delete the `upstream` and `upstreamLock` sections of the `Kptfile` in `mysql` directory.
 
 [create a new package]: /book/03-packages/05-creating-a-package

site/book/03-packages/07-publishing-a-package.md

@@ -17,7 +17,7 @@ $ cd wordpress
 $ git add . && git commit -m "Add wordpress package"
 ```
 
-Tag and pushes the commit:
+Tag and push the commit:
 
 ```shell
 $ git tag v0.1
@@ -35,7 +35,7 @@ $ kpt pkg get <MY_REPO_URL>/@v0.1
 You may have a Git repo containing multiple packages. kpt provides a tagging
 convention to enable packages to be independently versioned.
 
-For example, let's assume the `wordpress` directory is not at the root of the repo,
+For example, let's assume the `wordpress` directory is not at the root of the repo
 but instead is in the directory `packages/wordpress`:
 
 ```shell