docs: address some review comments from the docs repository

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

README.md

@@ -96,7 +96,7 @@ Buildx will always build using the BuildKit engine and does not require `DOCKER_
 
 Buildx build command supports the features available for `docker build` including the new features in Docker 19.03 such as outputs configuration, inline build caching or specifying target platform. In addition, buildx supports new features not yet available for regular `docker build` like building manifest lists, distributed caching, exporting build results to OCI image tarballs etc.
 
-Buildx is supposed to be flexible and can be run in different configurations that are exposed through a driver concept. Currently, we support a "docker" driver that uses the BuildKit library bundled into the docker daemon binary, and a "docker-container" driver that automatically launches BuildKit inside a Docker container. We plan to add more drivers in the future, for example, one that would allow running buildx inside an (unprivileged) container.
+Buildx is supposed to be flexible and can be run in different configurations that are exposed through a driver concept. Currently, we support a "docker" driver that uses the BuildKit library bundled into the Docker daemon binary, and a "docker-container" driver that automatically launches BuildKit inside a Docker container. We plan to add more drivers in the future, for example, one that would allow running buildx inside an (unprivileged) container.
 
 The user experience of using buildx is very similar across drivers, but there are some features that are not currently supported by the "docker" driver, because the BuildKit library bundled into docker daemon currently uses a different storage component. In contrast, all images built with "docker" driver are automatically added to the "docker images" view by default, whereas when using other drivers the method for outputting an image needs to be selected with `--output`.
 
@@ -109,7 +109,7 @@ Buildx allows you to create new instances of isolated builders. This can be used
 
 New instances can be created with `docker buildx create` command. This will create a new builder instance with a single node based on your current configuration. To use a remote node you can specify the `DOCKER_HOST` or remote context name while creating the new builder. After creating a new instance you can manage its lifecycle with the `inspect`, `stop` and `rm` commands and list all available builders with `ls`. After creating a new builder you can also append new nodes to it.
 
-To switch between different builders use `docker buildx use <name>`. After running this command the build commands would automatically keep using this builder.
+To switch between different builders, use `docker buildx use <name>`. After running this command the build commands would automatically keep using this builder.
 
 Docker 19.03 also features a new `docker context` command that can be used for giving names for remote Docker API endpoints. Buildx integrates with `docker context` so that all of your contexts automatically get a default builder instance. While creating a new builder instance or when adding a node to it you can also set the context name as the target.
 

docs/reference/buildx_build.md

@@ -45,7 +45,7 @@ Start a build
 The `buildx build` command starts a build using BuildKit. This command is similar
 to the UI of `docker build` command and takes the same flags and arguments.
 
-For documentation on most of these flags refer to the [`docker build`
+For documentation on most of these flags, refer to the [`docker build`
 documentation](https://docs.docker.com/engine/reference/commandline/build/). In
 here we’ll document a subset of the new flags.
 
@@ -67,12 +67,12 @@ values as an input separated by a comma. With multiple values the result will be
 built for all of the specified platforms and joined together into a single manifest
 list.
 
-If the`Dockerfile` needs to invoke the `RUN` command, the builder needs runtime
+If the `Dockerfile` needs to invoke the `RUN` command, the builder needs runtime
 support for the specified platform. In a clean setup, you can only execute `RUN`
 commands for your system architecture.
 If your kernel supports [`binfmt_misc`](https://en.wikipedia.org/wiki/Binfmt_misc)
-launchers for secondary architectures buildx will pick them up automatically.
-Docker desktop releases come with binfmt_misc automatically configured for `arm64`
+launchers for secondary architectures, buildx will pick them up automatically.
+Docker desktop releases come with `binfmt_misc` automatically configured for `arm64`
 and `arm` architectures. You can see what runtime platforms your current builder
 instance supports by running `docker buildx inspect --bootstrap`.
 
@@ -171,7 +171,7 @@ tar will be loaded automatically to the current docker instance.
 #### `image`
 
 The `image` exporter writes the build result as an image or a manifest list. When
-using `docker` driver the image will appear in `docker images`. Optionally image
+using `docker` driver the image will appear in `docker images`. Optionally, image
 can be automatically pushed to a registry by specifying attributes.
 
 Attribute keys:

docs/reference/buildx_create.md

@@ -33,11 +33,11 @@ Create makes a new builder instance pointing to a docker context or endpoint,
 where context is the name of a context from `docker context ls` and endpoint is
 the address for docker socket (eg. `DOCKER_HOST` value).
 
-By default, the current docker configuration is used for determining the
+By default, the current Docker configuration is used for determining the
 context/endpoint value.
 
 Builder instances are isolated environments where builds can be invoked. All
-docker contexts also get the default builder instance.
+Docker contexts also get the default builder instance.
 
 ## Examples
 

docs/reference/buildx_imagetools_create.md

@@ -25,10 +25,10 @@ Create a new image based on source images
 Imagetools contains commands for working with manifest lists in the registry.
 These commands are useful for inspecting multi-platform build results.
 
-Create creates a new manifest list based on source manifests. The source
-manifests can be manifest lists or single platform distribution manifests and
-must already exist in the registry where the new manifest is created. If only
-one source is specified create performs a carbon copy.
+Create a new manifest list based on source manifests. The source manifests can
+be manifest lists or single platform distribution manifests and must already
+exist in the registry where the new manifest is created. If only one source is
+specified, create performs a carbon copy.
 
 ## Examples
 

docs/reference/buildx_inspect.md

@@ -50,9 +50,9 @@ Platforms: linux/arm64, linux/arm/v7, linux/arm/v6
 
 ### <a name="bootstrap"></a> Ensure that the builder is running before inspecting (--bootstrap)
 
-Use the `--bootstrap` option to ensures that the builder is running before
+Use the `--bootstrap` option to ensure that the builder is running before
 inspecting it. If the driver is `docker-container`, then `--bootstrap` starts
 the buildkit container and waits until it is operational. Bootstrapping is
-automatically done during build, it is thus not necessary. The same BuildKit
+automatically done during build, and therefore not necessary. The same BuildKit
 container is used during the lifetime of the associated builder node (as
 displayed in `buildx ls`).