docs(fix): typos, grammar, and improve clarity in rfcs.

ADOPTERS.md

@@ -1,6 +1,6 @@
 # Adopters
 
-This list represents the collection of organizations that are using PipeCD within their environments. If you are currently utilizing PipeCD and not yet on this list, we strongly encourage you to add your organization here as well!
+This list represents the collection of organizations that are using PipeCD within their environments. If you are currently using PipeCD and not yet on this list, we strongly encourage you to add your organization here as well!
 
 The objective of this list is to serve as a comprehensive and authoritative resource for the entire PipeCD adopter community, while also inspiring those who are embarking on their PipeCD journey.
 

docs/rfcs/0002-lambda-deployment.md

@@ -3,7 +3,7 @@
 
 # Summary
 
-This RFC proposes adding a new service deployment from PipeCD: AWS Lambda deployment. Similar to the current [Google clould run deployment](https://pipecd.dev/docs/feature-status/#cloudrun-deployment).
+This RFC proposes adding a new service deployment from PipeCD: AWS Lambda deployment. Similar to the current [Google cloud run deployment](https://pipecd.dev/docs/feature-status/#cloudrun-deployment).
 
 # Motivation
 
@@ -58,7 +58,7 @@ Lambda function could also be deployed via source code by 2 steps method:
 1. Configure piped to be able to clone the source of Lambda function ( on the same repo which deployment be handled by piped or via remote git repo ).
 2. Compress the source code and deploy with [SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-command-reference.html) or using [aws-sdk](https://github.com/aws/aws-lambda-go) ( piped handle the deployment ).
 
-The deployment configuration sample as bellow:
+The deployment configuration sample as below:
 
 In case of source code for Lambda function is on the same repo handled by Piped
 ```yaml

docs/rfcs/0007-deployment-chain.md

@@ -105,7 +105,7 @@ The above configuration will provide a deployment chain as follow
 
 ## More examples regards known use-cases
 
-The above configuration contains sample for a completely flexsible deployment chain (multiple applications with difference kinds deployed across environment). For clarity, here are some examples for each known use-cases listed in [above section](#motivation)
+The above configuration contains a sample for a completely flexible deployment chain (multiple applications with different kinds deployed across environments). For clarity, here are some examples for each known use-cases listed in [above section](#motivation)
 
 ### Use-case <1>: chain of deployments contains multiple applications cross kinds
 ![image](assets/deployment-chain-kind.png)

docs/rfcs/0010-custom-stage.md

@@ -7,7 +7,7 @@ This RFC introduces a new way to enable users to use “custom stages” that us
 
 # Motivation
 
-Currently, users can use only stages that PipeCD have already defined. But some users want to define new stages by their use-cases as bellow. 
+Currently, users can use only stages that PipeCD have already defined. But some users want to define new stages by their use-cases as below. 
 
 - Deploying infrastructure by tools other than that PipeCD supports (terraform and kubernetes) such as SAM, cloud formation….
 - Running End to End tests
@@ -64,7 +64,7 @@ spec:
 
 ## Variable/Secret Management
 
-Users can use [encrypted-secret]([https://pipecd.dev/docs/user-guide/managing-application/secret-management/](https://pipecd.dev/docs/user-guide/managing-application/secret-management/)) and environment variables in scripts as bellow.
+Users can use [encrypted-secret]([https://pipecd.dev/docs/user-guide/managing-application/secret-management/](https://pipecd.dev/docs/user-guide/managing-application/secret-management/)) and environment variables in scripts as below.
 
 ```yaml
 apiVersion: pipecd.dev/v1beta1

docs/rfcs/0014-multi-cluster-deployment-for-k8s.md

@@ -247,14 +247,14 @@ Performs Drift Detection based on the livestate of all platform providers deploy
 Currently, we need to prepare the kubeconfig file manually.
 But it would be nice to prepare it automatically.
 
-It might realize it by using cloud vender feature, for example using Workload Identity on GKE, or IRSA on EKS.
-It means piped get kubeconfig when it starts by using them.
+It might be possible by using cloud vendor features, for example using Workload Identity on GKE, or IRSA on EKS.
+This would allow piped to obtain the kubeconfig at startup.
 
 # Alternatives
 
 ## Idea: Execute Stages in parallel within a pipeline
 
-![image](assets/0014-pipeline-paralell-stage.png)
+![image](assets/0014-pipeline-parallel-stage.png)
 
 ### UX
 

docs/rfcs/0015-pipecd-plugin-arch-meta.md

@@ -3,27 +3,27 @@
 
 # Summary
 
-This can be consider as the biggest step forward to make PipeCD fit its vision: The one CD for all.
+This can be considered as the biggest step forward to make PipeCD fit its vision: The one CD for all.
 
 # Motivation
 
-Up to this time, PipeCD archived several goals as its defined design in the initial stage, which included "being a consistent interface which can be used to make progressive delivery process easy for many application platforms". As its goal, the PipeCD currently supports 5 kind of application platforms, which are Kubernetes, ECS, Terraform, Lambda, and Cloud Run. But we want it not just like that, we want to make PipeCD support progressive delivery for whatever application platforms the market use today.
+Up to this time, PipeCD achieved several goals as its defined design in the initial stage, which included "being a consistent interface which can be used to make progressive delivery process easy for many application platforms". As its goal, the PipeCD currently supports 5 kind of application platforms, which are Kubernetes, ECS, Terraform, Lambda, and Cloud Run. But we want it not just like that, we want to make PipeCD support progressive delivery for whatever application platforms the market use today.
 
 To achieve that goal, there is only one way, which enables PipeCD to accept new platforms as plugin of the piped agent, which can free the limit of what platform PipeCD could support as a CD system.
 
 Also, with the power of plugin architecture, PipeCD can allow multi-versions of the same platform plugin, say the same plugin for CD on Kubernetes, but one is built-in and the other implemented by other developers. That is the future of PipeCD, and the maintainer team wants to bring it to.
 
 # Detailed design
 
-At the time this RFC is writen, there was serveral issues created on PipeCD main repo for tracking the plugin architecture tasks. This RFC summarizes the decisions the maintainer team has agreed to regarding the design of the PipeCD plugin architecture.
+At the time this RFC is written, there were several issues created on PipeCD main repo for tracking the plugin architecture tasks. This RFC summarizes the decisions the maintainer team has agreed to regarding the design of the PipeCD plugin architecture.
 
 After this line in the documentation, pipedv1 is a mention to plugin-arch piped, while pipedv0 is a mention to up-to-now piped.
 
 ## The approach
 
-We agreed that pipedv0 will be supported as least until the end of 2025, which mean we have to find a way to ensure our single PipeCD control plane can work with both pipedv0 and pipedv1 at the same time. That leads to this issue at [pipecd/issues/5252](https://github.com/pipe-cd/pipecd/issues/5252).
+We agreed that pipedv0 will be supported at least until the end of 2025, which means we have to find a way to ensure our single PipeCD control plane can work with both pipedv0 and pipedv1 at the same time. That leads to this issue at [pipecd/issues/5252](https://github.com/pipe-cd/pipecd/issues/5252).
 
-The key point of the control plane supports both pipedv0 and v1 approach is: platform related concepts like platform provider and kind are remained on the data model (for pipedv0), but we don't adding logic based on those concepts anymore. Pipedv1 logic will be built only around the plugins.
+The key point of the control plane supports both pipedv0 and v1 approach is: platform related concepts like platform provider and kind are remained on the data model (for pipedv0), but we don't add logic based on those concepts anymore. Pipedv1 logic will be built only around the plugins.
 
 As at this point, we have migration plan for platform related concepts in configuration as below
 
@@ -189,19 +189,19 @@ The configuration which up-to-now placed in piped and application (kind specific
 
 ![](assets/0015-config-context.png)
 
-We need futher discussion on this but currently, we agreed to separate configuration as piped context and plugin context as above.
+We need further discussion on this but currently, we agreed to separate configuration as piped context and plugin context as above.
 
 ### The interfaces
 
-The Piped agent has serveral main features, which are
+The Piped agent has several main features, which are
 
 - Plan and execute deployment
 - Calculate the plan preview result
 - Calculate the drift between live and "git source" manifests
 - Fetch and build the state of the live manifest
 - Insight feature
 
-Across these features, we have to support 5 kinds of platforms (up to now), and each deployment we have serveral kind of stages, which are
+Across these features, we have to support 5 kinds of platforms (up to now), and each deployment we have several kinds of stages, which are
 
 - K8s stages
 - Cloud run stages

docs/rfcs/0017-deployment-trace.md

@@ -44,7 +44,7 @@ message DeploymentTrace {
 }
 ```
 
-The idea is to use `commit_hash` to the reference keys to link between a deployment trace with all deployments triggred by the same change in application repo (commit_hash referrenced commit). Once we could built the deploymen trace object that contains commit_hash and add `commit_hash` value to deployment model objects, we can query for deployment trace and show it to the UI.
+The idea is to use `commit_hash` to the reference keys to link between a deployment trace with all deployments triggered by the same change in application repo (commit_hash referenced commit). Once we build the deployment trace object that contains commit_hash and add `commit_hash` value to deployment model objects, we can query for deployment trace and show it to the UI.
 
 The deployment model will add one field like this