diff --git a/docs/proposals/build-execution-using-build-run.md b/docs/proposals/build-execution-using-build-run.md
index bab2da7535..dbae766e8f 100644
--- a/docs/proposals/build-execution-using-build-run.md
+++ b/docs/proposals/build-execution-using-build-run.md
@@ -34,7 +34,7 @@ spec:
     name: kaniko-golang-build
 ```
 
-The `BuildRun` API also provides a way to override/specify  execution time information. 
+The `BuildRun` API also provides a way to override/specify execution time information.
 
 As an example, a `Build` configuration should not have to accurately specify the resource requirements - the information on resource requirements is valuable at build execution time which varies from environment to environment.
 
@@ -83,7 +83,7 @@ The above is a non-exhaustive list of questions that should help us modify the B
 
 ### Next steps / Consequences
 
-Here's what it means to adopt this proposal: 
+Here's what it means to adopt this proposal:
 
 1. Make `spec.output` optional in `Build` API's `spec` .
 2. Introduce `spec.output` in the `BuildRun` API's `spec`.
diff --git a/docs/proposals/buildstrategy-steps-resources.md b/docs/proposals/buildstrategy-steps-resources.md
index 2419b23de7..e8cb3368a1 100644
--- a/docs/proposals/buildstrategy-steps-resources.md
+++ b/docs/proposals/buildstrategy-steps-resources.md
@@ -54,8 +54,8 @@ there could be situations where containers under the same strategy required diff
 
 ## Motivation
 
-For strategies with multiple steps like Buildpacks, not all the steps(_containers_) will require the same set of resources(_e.g. memory, cpu, etc_) values. 
-In order to be able to manage situations where setting particular steps resources is required, we need a more flexible way to deal with N number of steps under the same strategy (_Build/ClusterBuildStrategy_). Also, we still need to help users to know that independently of the abstraction of the strategies, there are options for speeding up the builds. This options could be presented in the form of different `flavours` of the same strategy(_cluster or namespaced scope_), that differ between each other in terms of container resources values.
+For strategies with multiple steps like Buildpacks, not all the steps (_containers_) will require the same set of resources (_e.g. memory, cpu, etc_) values.
+In order to be able to manage situations where setting particular steps resources is required, we need a more flexible way to deal with N number of steps under the same strategy (_Build/ClusterBuildStrategy_). Also, we still need to help users to know that independently of the abstraction of the strategies, there are options for speeding up the builds. This options could be presented in the form of different `flavours` of the same strategy (_cluster or namespaced scope_), that differ between each other in terms of container resources values.
 
 ### Goals