diff --git a/config.toml b/config.toml
index 0b432d95..141260d8 100644
--- a/config.toml
+++ b/config.toml
@@ -3,7 +3,7 @@ title = "Shipwright"
 
 enableRobotsTXT = true
 
-# Hugo allows theme composition (and inheritance). The precedence is from left to right.
+# Hugo enables theme composition (and inheritance). The precedence is from left to right.
 theme = ["docsy"]
 
 # Will give values to .Lastmod etc.
@@ -82,13 +82,13 @@ copyright = "The Shipwright Contributors"
 # This menu appears only if you have at least one [params.versions] set.
 version_menu = "Releases"
 
-# Flag used in the "version-banner" partial to decide whether to display a 
+# Flag used in the "version-banner" partial to decide whether to display a
 # banner on every page indicating that this is an archived version of the docs.
 # Set this flag to "true" if you want to display the banner.
 archived_version = false
 
 # The version number for the version of the docs represented in this doc set.
-# Used in the "version-banner" partial to display a version number for the 
+# Used in the "version-banner" partial to display a version number for the
 # current doc set.
 version = "0.0"
 
@@ -132,12 +132,12 @@ footer_about_disable = false
 # add "hide_feedback: true" to the page's front matter.
 [params.ui.feedback]
 enable = true
-# The responses that the user sees after clicking "yes" (the page was helpful) or "no" (the page was not helpful).
+# The responses that the reader sees after clicking "yes" (the page was helpful) or "no" (the page was not helpful).
 yes = 'Glad to hear it! Please <a href="https://github.com/USERNAME/REPOSITORY/issues/new">tell us how we can improve</a>.'
 no = 'Sorry to hear that. Please <a href="https://github.com/USERNAME/REPOSITORY/issues/new">tell us how we can improve</a>.'
 
 # Adds a reading time to the top of each doc.
-# If you want this feature, but occasionally need to remove the Reading time from a single page, 
+# If you want this feature, but occasionally need to remove the Reading time from a single page,
 # add "hide_readingtime: true" to the page's front matter
 [params.ui.readingtime]
 enable = false
diff --git a/content/en/blog/posts/2020-11-30-intro-shipwright-pt2.md b/content/en/blog/posts/2020-11-30-intro-shipwright-pt2.md
index be338f92..d0d833bb 100644
--- a/content/en/blog/posts/2020-11-30-intro-shipwright-pt2.md
+++ b/content/en/blog/posts/2020-11-30-intro-shipwright-pt2.md
@@ -17,25 +17,25 @@ build container images on Kubernetes.
 
 ## Recap - From Binaries to Images
 
-Recall in [Part 1](/blog/2020/10/21/introducing-shipwright-part-1/), developers who moved from 
+Recall in [Part 1](/blog/2020/10/21/introducing-shipwright-part-1/), developers who moved from
 VM-based deployments to [Kubernetes](https://kubernetes.io/) needed to shift their unit of delivery
 from binaries to container images. Teams adopted various tools to accomplish this task, ranging
 from [Docker/Moby](https://mobyproject.org/) to [Cloud-Native Buildpacks](https://buildpacks.io/).
 New cloud-native applications like [Jenkins-X](https://jenkins-x.io/) and
 [Tekton](https://tekton.dev/) have emerged to deliver these container images on Kubernetes.
-[Jenkins](https://www.jenkins.io/) - the predecessor to Jenkins-X - has continued to play a 
+[Jenkins](https://www.jenkins.io/) - the predecessor to Jenkins-X - has continued to play a
 prominent role in automating the building and testing of applications.
 
 Building a container image on Kubernetes is not a simple feat. There are a wide variety of tools
 available, some which require knowledge on how to write a Dockerfile, others which do not or are
-tailored for specific programming languages. For CI/CD platforms like Tekton, setting up a build 
+tailored for specific programming languages. For CI/CD platforms like Tekton, setting up a build
 pipeline requires extensive configuration and customization. These are burdens that are difficult
 to overcome for many development teams.
 
 ## Shipwright Builds - A Framework for Building Images
 
 With Shipwright, we want to create an open and flexible framework that allows teams to easily build
-container images on Kubernetes. Much of the work has been inspired by OpenShift/okd, which provides 
+container images on Kubernetes. Much of the work has been inspired by OpenShift/okd, which provides
 its own API for building images. At the heart of every build are the following core components:
 
 1. Source code - the "what" you are trying to build
@@ -62,18 +62,18 @@ Developers who use docker are familiar with this process:
 
 The Build API consists of four core Custom Resource Definitions (CRDs):
 
-1. `BuildStrategy` and `ClusterBuildStrategy` - defines how to build an application for an image 
+1. `BuildStrategy` and `ClusterBuildStrategy` - defines how to build an application for an image
    building tool.
 2. `Build` - defines what to build, and where the application should be delivered.
 3. `BuildRun` - invokes the build, telling the Kubernetes cluster when to build your application.
 
 ### BuildStrategy and ClusterBuildStrategy
 
-`BuildStrategy` and `ClusterBuildStrategy` are related APIs to define how a given tool should be 
+`BuildStrategy` and `ClusterBuildStrategy` are related APIs to define how a given tool should be
 used to assemble an application. They are distinguished by their scope - `BuildStrategy` objects
 are namespace scoped, whereas `ClusterBuildStrategy` objects are cluster scoped.
 
-The spec consists of a `buildSteps` object, which look and feel like Kubernetes `Container` 
+The spec consists of a `buildSteps` object, which look and feel like Kubernetes `Container`
 specifications. Below is an example spec for Kaniko, which can build an image from a
 Dockerfile within a container:
 
@@ -142,7 +142,7 @@ is possible.
 
 ### BuildRun
 
-Each `BuildRun` object invokes a build on your cluster. You can think of these as a Kubernetes 
+Each `BuildRun` object invokes a build on your cluster. You can think of these as a Kubernetes
 `Jobs` or Tekton `TaskRuns` - they represent a workload on your cluster, ultimately resulting in a
 running `Pod`.
 
@@ -169,9 +169,9 @@ step:
 1. `/tekton/home`
 2. `/workspace`
 
-Where do these directories come from? Shipwright is built on top of [Tekton](https://tekton.dev/), 
-taking advantage of its features to simpify CI/CD workloads. Among the things that Tekton provides 
-is a Linux user `$HOME` directory (`/tekton/home`) and a workspace where the application can be 
+Where do these directories come from? Shipwright is built on top of [Tekton](https://tekton.dev/),
+taking advantage of its features to simpify CI/CD workloads. Among the things that Tekton provides
+is a Linux user `$HOME` directory (`/tekton/home`) and a workspace where the application can be
 assembled (`/workspace`).
 
 ## Try it!
@@ -185,6 +185,6 @@ If your cluster has [Operator Lifecycle Manager](https://olm.operatorframework.i
 option 2 is the recommened approach. OLM will take care of installing Tekton as well as Shipwright.
 
 The samples contain build strategies for container-based image build tools like
-[Kaniko](https://github.com/GoogleContainerTools/kaniko), [Buildah](https://buildah.io/), 
-[Source-to-Image](https://github.com/openshift/source-to-image) and 
+[Kaniko](https://github.com/GoogleContainerTools/kaniko), [Buildah](https://buildah.io/),
+[Source-to-Image](https://github.com/openshift/source-to-image) and
 [Cloud-Native Buildpacks](https://buildpacks.io/).
diff --git a/content/en/docs/api/build.md b/content/en/docs/api/build.md
index 7ba758a4..12772393 100644
--- a/content/en/docs/api/build.md
+++ b/content/en/docs/api/build.md
@@ -16,7 +16,7 @@ weight: 10
 
 ## Overview
 
-A `Build` resource allows the user to define:
+A `Build` resource enables the user to define:
 
 - source
 - sources
@@ -41,19 +41,19 @@ When the controller reconciles it:
 
 ## Build Validations
 
-In order to prevent users from triggering `BuildRuns` (_execution of a Build_) that will eventually fail because of wrong or missing dependencies or configuration settings, the Build controller will validate them in advance. If all validations are successful, users can expect a `Succeeded` `Status.Reason`, however if any of the validations failed, users can rely on the `Status.Reason` and `Status.Message` fields, in order to understand the root cause.
+To prevent users from triggering `BuildRuns` (_execution of a Build_) that will eventually fail because of wrong or missing dependencies or configuration settings, the Build controller will validate them in advance. If all validations are successful, users can expect a `Succeeded` `Status.Reason`. However, if any validations fail, users can rely on the `Status.Reason` and `Status.Message` fields to understand the root cause.
 
 | Status.Reason | Description |
 | --- | --- |
 | BuildStrategyNotFound   | The referenced namespace-scope strategy doesn't exist. |
 | ClusterBuildStrategyNotFound   | The referenced cluster-scope strategy doesn't exist. |
-| SetOwnerReferenceFailed   | Setting ownerreferences between a Build and a BuildRun failed. This is triggered when making use of the `build.shipwright.io/build-run-deletion` annotation in a Build. |
+| SetOwnerReferenceFailed   | Setting ownerreferences between a Build and a BuildRun failed. This message is triggered when making use of the `build.shipwright.io/build-run-deletion` annotation in a Build. |
 | SpecSourceSecretRefNotFound | The secret used to authenticate to git doesn't exist. |
 | SpecOutputSecretRefNotFound | The secret used to authenticate to the container registry doesn't exist. |
 | SpecBuilderSecretRefNotFound | The secret used to authenticate to the container registry doesn't exist.|
 | MultipleSecretRefNotFound | More than one secret is missing. At the moment, only three paths on a Build can specify a secret. |
-| RuntimePathsCanNotBeEmpty | The Runtime feature is used, but the runtime path was not defined. This is mandatory. |
-| RemoteRepositoryUnreachable | The defined `spec.source.url` was not found. This validation only take place for http/https protocols. |
+| RuntimePathsCanNotBeEmpty | The Runtime feature is used, but the runtime path was not defined. This path is mandatory. |
+| RemoteRepositoryUnreachable | The defined `spec.source.url` was not found. This validation only takes place for HTTP/HTTPS protocols. |
 
 ## Configuring a Build
 
@@ -72,8 +72,8 @@ The `Build` definition supports the following fields:
 - Optional:
   - `spec.parameters` - Refers to a list of `name-value` that could be used to loosely type parameters in the `BuildStrategy`.
   - `spec.dockerfile` - Path to a Dockerfile to be used for building an image. (_Use this path for strategies that require a Dockerfile_)
-  - `spec.sources` - [Sources](#Sources) describes a slice of artifacts that will be imported into project context, before the actual build process starts.
-  - `spec.runtime` - Runtime-Image settings, to be used for a multi-stage build. ⚠️ Deprecated
+  - `spec.sources` - [Sources](#Sources) describes a slice of artifacts to import into project context before the actual build process starts.
+  - `spec.runtime` - Runtime-Image settings to use for a multi-stage build. ⚠️ Deprecated
   - `spec.timeout` - Defines a custom timeout. The value needs to be parsable by [ParseDuration](https://golang.org/pkg/time/#ParseDuration), for example `5m`. The default is ten minutes. The value can be overwritten in the `BuildRun`.
   - `metadata.annotations[build.shipwright.io/build-run-deletion]` - Defines if delete all related BuildRuns when deleting the Build. The default is `false`.
 
@@ -81,13 +81,13 @@ The `Build` definition supports the following fields:
 
 A `Build` resource can specify a Git source, together with other parameters like:
 
-- `source.credentials.name` - For private repositories, the name is a reference to an existing secret on the same namespace containing the `ssh` data.
-- `source.revision` - An specific revision to select from the source repository, this can be a commit or branch name. If not defined, it will fallback to the git repository default branch.
-- `source.contextDir` - For repositories where the source code is not located at the root folder, you can specify this path here. Currently, only supported by `buildah`, `kaniko` and `buildpacks` build strategies.
+- `source.credentials.name` - For private repositories, the name refers to an existing secret on the same namespace containing the `ssh` data.
+- `source.revision` - An specific revision to select from the source repository; this can be a commit or branch name. If not defined, it will fall back to the git repository default branch.
+- `source.contextDir` - For repositories where the source code is not located at the root folder, you can specify this path here. Currently, only supported by `buildah`, `kaniko`, and `buildpacks` build strategies.
 
 By default, the Build controller won't validate that the Git repository exists. If the validation is desired, users can define the `build.shipwright.io/verify.repository` annotation with `true` explicitly. For example:
 
-Example of a `Build` with the **build.shipwright.io/verify.repository** annotation, in order to enable the `spec.source.url` validation.
+Example of a `Build` with the **build.shipwright.io/verify.repository** annotation to enable the `spec.source.url` validation.
 
 ```yaml
 apiVersion: shipwright.io/v1alpha1
@@ -102,9 +102,11 @@ spec:
     contextDir: docker-build
 ```
 
-_Note_: The Build controller only validates two scenarios. The first one where the endpoint uses an `http/https` protocol, the second one when a `ssh` protocol (_e.g. `git@`_) is defined and none referenced secret was provided(_e.g. source.credentials.name_).
+_Note_: The Build controller validates only two scenarios:
+- When the endpoint uses an `http/https` protocol.
+- When the `ssh` protocol (_e.g., `git@`_) is defined but no referenced secret was provided(_e.g., source.credentials.name_).
 
-Example of a `Build` with a source with **credentials** defined by the user.
+The following example shows a `Build` where you use `credentials` to define a source:
 
 ```yaml
 apiVersion: shipwright.io/v1alpha1
@@ -118,7 +120,7 @@ spec:
       name: source-repository-credentials
 ```
 
-Example of a `Build` with a source that specifies an specific subfolder on the repository.
+Example of a `Build` with a source that specifies a subfolder on the repository.
 
 ```yaml
 apiVersion: shipwright.io/v1alpha1
@@ -131,7 +133,7 @@ spec:
     contextDir: renamed
 ```
 
-Example of a `Build` that specifies an specific branch on the git repository:
+Example of a `Build` that specifies a branch on the git repository:
 
 ```yaml
 apiVersion: shipwright.io/v1alpha1
@@ -155,7 +157,7 @@ A `Build` resource can specify the `BuildStrategy` to use, these are:
 - [ko](buildstrategies.md#ko)
 - [Source-to-Image](buildstrategies.md#source-to-image)
 
-Defining the strategy is straightforward, you need to define the `name` and the `kind`. For example:
+Defining the strategy is straightforward; you need to define the `name` and the `kind`. For example:
 
 ```yaml
 apiVersion: shipwright.io/v1alpha1
@@ -170,7 +172,9 @@ spec:
 
 ### Defining the Builder or Dockerfile
 
-A `Build` resource can specify an image containing the tools to build the final image. Users can do this via the `spec.builder` or the `spec.dockerfile`. For example, the user choose  the `Dockerfile` file under the source repository.
+To define the image that contains the tools that build the final image, you specify the value of `spec.dockerfile` or `spec.builder` in a `Build` resource.
+
+In the following example, the `Build` resource sets the value of `spec.dockerfile` to `Dockerfile` under the source repository:
 
 ```yaml
 apiVersion: shipwright.io/v1alpha1
@@ -187,7 +191,7 @@ spec:
   dockerfile: Dockerfile
 ```
 
-Another example, when the user chooses to use a `builder` image ( This is required for `source-to-image` buildStrategy, because for different code languages, they have different builders. ):
+Or, for example, the following `Build` resource employs the source-to-image (S2I) build strategy. It does this by setting the value of `spec.builder.image` to an image that can build the source code.
 
 ```yaml
 apiVersion: shipwright.io/v1alpha1
@@ -207,9 +211,9 @@ spec:
 
 ### Defining the Output
 
-A `Build` resource can specify the output where the image should be pushed. For external private registries it is recommended to specify a secret with the related data to access it.
+A `Build` resource can specify the output where the image should be pushed. For external private registries, it is recommended to specify a secret with the related data to access it.
 
-For example, the user specify a public registry:
+For example, the user specifies a public registry:
 
 ```yaml
 apiVersion: shipwright.io/v1alpha1
@@ -229,7 +233,7 @@ spec:
     image: image-registry.openshift-image-registry.svc:5000/build-examples/nodejs-ex
 ```
 
-Another example, is when the user specifies a private registry:
+Another example is when the user specifies a private registry:
 
 ```yaml
 apiVersion: shipwright.io/v1alpha1
@@ -282,9 +286,9 @@ At this initial stage, authentication is not supported therefore you can only do
 **⚠️ Deprecated:** This feature is deprecated and will be removed in a future release.
 See https://github.com/shipwright-io/community/blob/main/ships/deprecate-runtime.md for more information.
 
-Runtime-image is a new image composed with build-strategy outcome. On which you can compose a multi-stage image build, copying parts out the original image into a new one. This feature allows replacing the base-image of any container-image, creating leaner images, and other use-cases.
+A runtime-image is a new image composed with build-strategy outcome. On which you can compose a multi-stage image build, copying parts from the original image into a new one. This feature enables replacing the base image of any container image, creating leaner images, and other use-cases.
 
-The following examples illustrates how to the `runtime`:
+The following examples illustrate how to the `runtime`:
 
 ```yml
 apiVersion: shipwright.io/v1alpha1
@@ -315,7 +319,7 @@ spec:
       - start
 ```
 
-This build will produce a Node.js based application where a single directory is imported from the image built by buildpacks strategy. The data copied is using the `.spec.runtime.user` directive, and the image also runs based on it.
+This build will produce a Node.js-based application where a single directory is imported from the image built by buildpacks strategy. The data copied uses the `.spec.runtime.user` directive, and the image also runs based on it.
 
 Please consider the description of the attributes under `.spec.runtime`:
 
@@ -326,19 +330,19 @@ Please consider the description of the attributes under `.spec.runtime`:
 - `.run`: arbitrary commands to be executed as `RUN` blocks, before `COPY`
 - `.user.name`: username employed on `USER` directive, and also to change ownership of files copied to the runtime-image
 - `.user.group`: group name (or GID), employed to change ownership and on `USER` directive
-- `.paths`: list of files or directory paths to be copied to runtime-image, those can be defined as `<source>:<destination>` split by colon (`:`). You can use the `$(workspace)` placeholder to access the directory where your source repository is cloned, if `spec.source.contextDir` is defined, then `$(workspace)` to context directory location
+- `.paths`: list of files or directory paths to be copied to runtime-image, those can be defined as `<source>:<destination>` split by a colon (`:`). You can use the `$(workspace)` placeholder to access the directory where your source repository is cloned, if `spec.source.contextDir` is defined, then `$(workspace)` to context directory location
 - `.entrypoint`: entrypoint command, specified as a list
 
 > ⚠️ **Image Tag Overwrite**
 >
-> Specifying the runtime section will cause a `BuildRun` to push `spec.output.image` twice. First, the image produced by chosen `BuildStrategy` is pushed, and next it gets reused to construct the runtime-image, which is pushed again, overwriting `BuildStrategy` outcome.
-> Be aware, specially in situations where the image push action triggers automation steps. Since the same tag will be reused, you might need to take this in consideration when using runtime-images.
+> Specifying the runtime section causes a `BuildRun` to push `spec.output.image` twice. First, the image produced by chosen `BuildStrategy` is pushed, and next, it gets reused to construct the runtime image, which is pushed again, overwriting `BuildStrategy` outcome.
+> Be aware, especially in situations where the image push action triggers automation steps. Since the same tag is reused, you might need to consider this when using runtime images.
 
-Under the cover, the runtime image will be an additional step in the generated Task spec of the TaskRun. It uses [Kaniko](https://github.com/GoogleContainerTools/kaniko) to run a container build using the `gcr.io/kaniko-project/executor:v1.6.0` image. You can overwrite this image by adding the environment variable `KANIKO_CONTAINER_IMAGE` to the [build controller deployment](../deploy/controller.yaml).
+Under the cover, the runtime image will be an additional step in the generated `Task` spec of the `TaskRun`. It uses [Kaniko](https://github.com/GoogleContainerTools/kaniko) to run a container build using the `gcr.io/kaniko-project/executor:v1.6.0` image. You can overwrite this image by adding the environment variable `KANIKO_CONTAINER_IMAGE` to the [build controller deployment](../deploy/controller.yaml).
 
 ## BuildRun deletion
 
-A `Build` can automatically delete a related `BuildRun`. To enable this feature set the  `build.shipwright.io/build-run-deletion` annotation to `true` in the `Build` instance. By default the annotation is never present in a `Build` definition. See an example of how to define this annotation:
+A `Build` can automatically delete a related `BuildRun`. To enable this feature set the `build.shipwright.io/build-run-deletion` annotation to `true` in the `Build` instance. By default, the annotation is never present in a `Build` definition. See an example of how to define this annotation:
 
 ```yaml
 apiVersion: shipwright.io/v1alpha1
diff --git a/content/en/docs/api/buildrun.md b/content/en/docs/api/buildrun.md
index 80998f53..04cd3d89 100644
--- a/content/en/docs/api/buildrun.md
+++ b/content/en/docs/api/buildrun.md
@@ -18,7 +18,7 @@ weight: 40
 
 The resource `BuildRun` (`buildruns.dev/v1alpha1`) is the build process of a `Build` resource definition which is executed in Kubernetes.
 
-A `BuildRun` resource allows the user to define:
+A `BuildRun` resource enables the user to define:
 
 - The `BuildRun` name, through which the user can monitor the status of the image construction.
 - A referenced `Build` instance to use during the build construction.
@@ -108,7 +108,7 @@ NAME                    SUCCEEDED   REASON      MESSAGE
 buildpacks-v3-buildrun  True        Succeeded   All Steps have completed executing   4m28s       16s
 ```
 
-The above allows users to get an overview of the building mechanism state.
+The above enables users to get an overview of the building mechanism state.
 
 ### Understanding the state of a BuildRun
 
@@ -145,14 +145,14 @@ _Note_: We heavily rely on the Tekton TaskRun [Conditions](https://github.com/te
 
 To make it easier for users to understand why did a BuildRun failed, users can infer from the `Status.FailedAt` field, the pod and container where the failure took place.
 
-In addition, the `Status.Conditions` will host under the `Message` field a compacted message containing the `kubectl` command to trigger, in order to retrieve the logs.
+In addition, the `Status.Conditions` will host under the `Message` field a compacted message containing the `kubectl` command to trigger, to retrieve the logs.
 
 ### Build Snapshot
 
-For every BuildRun controller reconciliation, the `buildSpec` in the Status of the `BuildRun` is updated if an existing owned `TaskRun` is present. During this update, a `Build` resource snapshot is generated and embedded into the `status.buildSpec` path of the `BuildRun`. A `buildSpec` is just a copy of the original `Build` spec, from where the `BuildRun` executed a particular image build. The snapshot approach allows developers to see the original `Build` configuration.
+For every BuildRun controller reconciliation, the `buildSpec` in the Status of the `BuildRun` is updated if an existing owned `TaskRun` is present. During this update, a `Build` resource snapshot is generated and embedded into the `status.buildSpec` path of the `BuildRun`. A `buildSpec` is just a copy of the original `Build` spec, from where the `BuildRun` executed a particular image build. The snapshot approach enables developers to see the original `Build` configuration.
 
 ## Relationship with Tekton Tasks
 
-The `BuildRun` resource abstracts the image construction by delegating this work to the Tekton Pipeline [TaskRun](https://github.com/tektoncd/pipeline/blob/main/docs/taskruns.md). Compared to a Tekton Pipeline [Task](https://github.com/tektoncd/pipeline/blob/main/docs/tasks.md), a `TaskRun` runs all `steps` until completion of the `Task` or until a failure occurs in the `Task`.
+The `BuildRun` resource abstracts the image construction by delegating this work to the Tekton Pipeline [TaskRun](https://github.com/tektoncd/pipeline/blob/main/docs/taskruns.md). Compared to a Tekton Pipeline [`Task`](https://github.com/tektoncd/pipeline/blob/main/docs/tasks.md), a `TaskRun` runs all `steps` until completion of the `Task` or until a failure occurs in the `Task`.
 
 The `BuildRun` controller during the Reconcile will generate a new `TaskRun`. During the execution, the controller will embed in the `TaskRun` `Task` definition the requires `steps` to execute. These `steps` are define in the strategy defined in the `Build` resource, either a `ClusterBuildStrategy` or a `BuildStrategy`.
diff --git a/content/en/docs/api/buildstrategies.md b/content/en/docs/api/buildstrategies.md
index 56cf5f2b..b866ba7d 100644
--- a/content/en/docs/api/buildstrategies.md
+++ b/content/en/docs/api/buildstrategies.md
@@ -173,7 +173,7 @@ kubectl apply -f samples/buildstrategy/ko/buildstrategy_ko_cr.yaml
 
 ## Source to Image
 
-This BuildStrategy is composed by [`source-to-image`][s2i] and [`kaniko`][kaniko] in order to generate a `Dockerfile` and prepare the application to be built later on with a builder.
+This BuildStrategy is composed by [`source-to-image`][s2i] and [`kaniko`][kaniko] to generate a `Dockerfile` and prepare the application to be built later on with a builder.
 
 `s2i` requires a specially crafted image, which can be informed as `builderImage` parameter on the `Build` resource.
 
@@ -187,7 +187,7 @@ kubectl apply -f samples/buildstrategy/source-to-image/buildstrategy_source-to-i
 
 ### Build Steps
 
-1. `s2i` in order to generate a `Dockerfile` and prepare source-code for image build;
+1. `s2i` to generate a `Dockerfile` and prepare source-code for image build;
 2. `kaniko` to create and push the container image to what is defined as `output.image`;
 
 [buildpacks]: https://buildpacks.io/
@@ -339,11 +339,11 @@ spec:
 
 ### How does Tekton Pipelines handle resources
 
-The **Build** controller relies on the Tekton [pipeline controller](https://github.com/tektoncd/pipeline) to schedule the `pods` that execute the above strategy steps. In a nutshell, the **Build** controller creates on run-time a Tekton **TaskRun**, and the **TaskRun** generates a new pod in the particular namespace. In order to build an image, the pod executes all the strategy steps one-by-one.
+The **Build** controller relies on the Tekton [pipeline controller](https://github.com/tektoncd/pipeline) to schedule the `pods` that execute the above strategy steps. In a nutshell, the **Build** controller creates on run-time a Tekton **TaskRun**, and the **TaskRun** generates a new pod in the particular namespace. To build an image, the pod executes all the strategy steps one-by-one.
 
 Tekton manage each step resources **request** in a very particular way, see the [docs](https://github.com/tektoncd/pipeline/blob/main/docs/tasks.md#defining-steps). From this document, it mentions the following:
 
-> The CPU, memory, and ephemeral storage resource requests will be set to zero, or, if specified, the minimums set through LimitRanges in that Namespace, if the container image does not have the largest resource request out of all container images in the Task. This ensures that the Pod that executes the Task only requests enough resources to run a single container image in the Task rather than hoard resources for all container images in the Task at once.
+> The CPU, memory, and ephemeral storage resource requests will be set to zero, or, if specified, the minimums set through LimitRanges in that Namespace, if the container image does not have the largest resource request out of all container images in the `Task`. This ensures that the Pod that executes the `Task` only requests enough resources to run a single container image in the `Task` rather than hoard resources for all container images in the `Task` at once.
 
 ### Examples of Tekton resources management