docs: fix spelling and grammar issues in docs-dev (#6357)

docs/content/en/docs-dev/concepts/_index.md

@@ -35,7 +35,7 @@ There are three types of project roles:
 
 ### Application
 
-A collect of resources (containers, services, infrastructure components...) and configurations that are managed together.
+A collection of resources (containers, services, infrastructure components...) and configurations that are managed together.
 PipeCD supports multiple kinds of applications such as `KUBERNETES`, `TERRAFORM`, `ECS`, `CLOUDRUN`, `LAMBDA`...
 
 ### Application Configuration

docs/content/en/docs-dev/installation/install-control-plane/installing-controlplane-on-k8s.md

@@ -111,7 +111,7 @@ kubectl port-forward svc/pipecd 8080 --namespace={NAMESPACE}
 
 Now go to [http://localhost:8080](http://localhost:8080) on your browser, you will see a page to login to your project.
 
-Up to here, you have a installed PipeCD's Control Plane. To logging in, you need to initialize a new project.
+Up to here, you have an installed PipeCD's Control Plane. To log in, you need to initialize a new project.
 
 ### 4. Initialize a new project
 

docs/content/en/docs-dev/migrating-from-v0-to-v1/_index.md

@@ -97,7 +97,7 @@ Or specify an entire directory:
 pipectl migrate application-config --dirs=path/to/apps/
 ```
 
-Here is an example for a simple app.pippcd.yaml file which demonstrates a kubernetes deployment and simulates a 30s wait:
+Here is an example for a simple app.pipecd.yaml file which demonstrates a Kubernetes deployment and simulates a 30s wait:
 
 ```yaml
 apiVersion: pipecd.dev/v1beta1

docs/content/en/docs-dev/overview/_index.md

@@ -61,8 +61,8 @@ PipeCD provides a unified continuous delivery solution for multiple application
 
 ## Where should I go next?
 
-For a good understanding of the PipeCD's components.
-- [Concepts](../concepts): describes each components.
+For a good understanding of PipeCD's components:
+- [Concepts](../concepts): describes each component.
 - [FAQ](../faq): describes the difference between PipeCD and other tools.
 
 If you are an **operator** wanting to install and configure PipeCD for other developers.

docs/content/en/docs-dev/quickstart/_index.md

@@ -106,7 +106,7 @@ After a bit, the first deployment is complete and will automatically sync the ap
 
 ![](/images/quickstart-first-deployment.png)
 
-For more about manage applications' deployment with PipeCD, referrence to [Managing application](/docs/user-guide/managing-application/)
+For more about managing applications' deployment with PipeCD, refer to [Managing application](/docs/user-guide/managing-application/)
 
 ### 3. Cleanup
 When you’re finished experimenting with PipeCD quickstart mode, you can uninstall it using:

docs/content/en/docs-dev/user-guide/managing-application/application-live-state.md

@@ -6,7 +6,7 @@ description: >
   The live states of application components as well as their health status.
 ---
 
-By default, `piped` continuously monitors the running resources/components of all deployed applications to determine the state of them and then send those results to the control plane. The application state will be visualized and rendered at the application details page in realtime. That helps developers can see what is running in the cluster as well as their health status. The application state includes:
+By default, `piped` continuously monitors the running resources/components of all deployed applications to determine their state and then sends those results to the control plane. The application state will be visualized and rendered on the application details page in real time. This helps developers see what is running in the cluster as well as their health status. The application state includes:
 - visual graph of application resources/components. Each resource/component node includes its metadata and health status.
 - health status of the whole application. Application health status is `HEALTHY` if and only if the health statuses of all of its resources/components are `HEALTHY`.
 

docs/content/en/docs-dev/user-guide/managing-application/cancelling-a-deployment.md

@@ -8,7 +8,7 @@ description: >
 
 A running deployment can be cancelled from web UI at the deployment details page.
 
-If the application rollback is enabled in the application configuration, the rollback process will be executed after the cancelling. You can also explicitly specify to rollback after the cancelling or not from the web UI by clicking on `▼` mark on the right side of the `CANCEL` button to select your option.
+If the application rollback is enabled in the application configuration, the rollback process will be executed after the cancellation. You can also explicitly specify whether to rollback after the cancellation or not from the web UI by clicking on `▼` mark on the right side of the `CANCEL` button to select your option.
 
 ![](/images/cancel-deployment.png)
 <p style="text-align: center;">

docs/content/en/docs-dev/user-guide/managing-application/configuration-drift-detection.md

@@ -46,7 +46,7 @@ The details shows why the application is in OUT_OF_SYNC state
 
 ###### DEPLOYING
 
-This status means the application is deploying and the configuration drift detection is not running a white. Whenever a new deployment of the application was started, the detection process will temporarily be stopped until that deployment finishes and will be continued after that.
+This status means the application is deploying and the configuration drift detection is not running for a while. Whenever a new deployment of the application is started, the detection process will temporarily be stopped until that deployment finishes and will be continued after that.
 
 ### How to enable
 

docs/content/en/docs-dev/user-guide/managing-application/customizing-deployment/adding-a-manual-approval.md

@@ -8,7 +8,7 @@ description: >
 
 While deploying an application to production environments, some teams require manual approvals before continuing.
 The manual approval stage enables you to control when the deployment is allowed to continue by requiring a specific person or team to approve.
-This stage is named by `WAIT_APPROVAL` and you can add it to your pipeline before some stages should be approved before they can be executed.
+This stage is named `WAIT_APPROVAL` and you can add it to your pipeline before some stages that should be approved before they can be executed.
 
 ``` yaml
 apiVersion: pipecd.dev/v1beta1

docs/content/en/docs-dev/user-guide/managing-application/customizing-deployment/adding-a-wait-stage.md

@@ -6,8 +6,8 @@ description: >
   This page describes how to add a WAIT stage.
 ---
 
-In addition to waiting for approvals from someones, the deployment pipeline can be configured to wait an amount of time before continuing.
-This can be done by adding the `WAIT` stage into the pipeline. This stage has one configurable field is `duration` to configure how long should be waited.
+In addition to waiting for approvals from someone, the deployment pipeline can be configured to wait an amount of time before continuing.
+This can be done by adding the `WAIT` stage into the pipeline. This stage has one configurable field, `duration`, to configure how long it should wait.
 
 ``` yaml
 apiVersion: pipecd.dev/v1beta1

docs/content/en/docs-dev/user-guide/managing-application/customizing-deployment/script-run.md

@@ -49,7 +49,7 @@ spec:
 ```
 
 You can define the command as `run`.
-Also, if you want to some values as variables, you can define them as `env`.
+Also, if you want to use some values as variables, you can define them as `env`.
 
 The commands run in the directory where this application configuration file exists.
 

docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/cloudrun.md

@@ -8,7 +8,7 @@ description: >
 
 *Note: Cloud Run job has not been supported yet.*
 
-Deploying a Cloud Run application requires a `service.yaml` file placing inside the application directory. That file contains the service specification used by Cloud Run as following: 
+Deploying a Cloud Run application requires a `service.yaml` file placed inside the application directory. That file contains the service specification used by Cloud Run as follows:
 
 ``` yaml
 apiVersion: serving.knative.dev/v1
@@ -42,7 +42,7 @@ Quick sync for a Cloud Run deployment will roll out the new version and switch a
 ## Sync with the specified pipeline
 
 The [pipeline](../../../configuration-reference/#cloud-run-application) field in the application configuration is used to customize the way to do the deployment.
-You can add a manual approval before routing traffic to the new version or add an analysis stage the do some smoke tests against the new version before allowing them to receive the real traffic.
+You can add a manual approval before routing traffic to the new version or add an analysis stage to do some smoke tests against the new version before allowing them to receive the real traffic.
 
 These are the provided stages for Cloud Run application you can use to build your pipeline:
 

docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/ecs.md

@@ -79,7 +79,7 @@ spec:
 ## Sync with the specified pipeline
 
 The [pipeline](../../../configuration-reference/#ecs-application) field in the application configuration is used to customize the way to do the deployment.
-You can add a manual approval before routing traffic to the new version or add an analysis stage the do some smoke tests against the new version before allowing them to receive the real traffic.
+You can add a manual approval before routing traffic to the new version or add an analysis stage to do some smoke tests against the new version before allowing them to receive the real traffic.
 
 These are the provided stages for ECS application you can use to build your pipeline:
 

docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/kubernetes.md

@@ -15,7 +15,7 @@ You can generate an application config file easily and interactively by [`pipect
 
 ## Quick sync
 
-Quick sync is a fast way to sync application to the state specified in the target Git commit without any progressive strategy. It just applies all the defined manifiests to sync the application.
+Quick sync is a fast way to sync application to the state specified in the target Git commit without any progressive strategy. It just applies all the defined manifests to sync the application.
 The quick sync will be planned in one of the following cases:
 - no pipeline was specified in the application configuration file
 - [pipeline](../../../configuration-reference/#pipeline) was specified but the PR did not make any changes on workload (e.g. Deployment's pod template) or config (e.g. ConfigMap, Secret)

docs/content/en/docs-dev/user-guide/managing-application/defining-app-configuration/lambda.md

@@ -6,7 +6,7 @@ description: >
   Specific guide to configuring deployment for Lambda application.
 ---
 
-Deploying a Lambda application requires a `function.yaml` file placing inside the application directory. That file contains values to be used to deploy Lambda function on your AWS cluster.
+Deploying a Lambda application requires a `function.yaml` file placed inside the application directory. That file contains values to be used to deploy Lambda function on your AWS cluster.
 Currently, Piped supports deploying all types of Lambda deployment packages:
 - container images (called [container image as Lambda function](https://aws.amazon.com/blogs/aws/new-for-aws-lambda-container-image-support/))
 - `.zip` file archives (which stored in AWS S3)
@@ -119,7 +119,7 @@ Quick sync for a Lambda deployment will roll out the new version and switch all
 ## Sync with the specified pipeline
 
 The [pipeline](../../../configuration-reference/#lambda-application) field in the application configuration is used to customize the way to do the deployment.
-You can add a manual approval before routing traffic to the new version or add an analysis stage the do some smoke tests against the new version before allowing them to receive the real traffic.
+You can add a manual approval before routing traffic to the new version or add an analysis stage to do some smoke tests against the new version before allowing them to receive the real traffic.
 
 These are the provided stages for Lambda application you can use to build your pipeline:
 

docs/content/en/docs-dev/user-guide/managing-application/deployment-chain.md

@@ -48,10 +48,10 @@ See [Examples](../../examples/#deployment-chain) for more specific.
 
 ## Deployment chain characteristic
 
-Something you need to care about while creating your deployment chain with PipeCD
+Something you need to be aware of while creating your deployment chain with PipeCD:
 
-1. The deployment chain blocks are run in sequence, one by one. But all nodes in the same block are run in parallel, you should ensure that all nodes(deployments) in the same block do not depend on each other.
-2. Once a node in a block has finished with `FAILURE` or `CANCELLED` status, the containing block will be set to fail, and all other nodes which have not yet finished will be set to `CANCELLED` status (those nodes will be rolled back if they're in the middle of its deploying process). Consequently, all blocks after that failed block will be set to `CANCELLED` status and be stopped.
+1. The deployment chain blocks are run in sequence, one by one. But all nodes in the same block are run in parallel, you should ensure that all nodes (deployments) in the same block do not depend on each other.
+2. Once a node in a block has finished with `FAILURE` or `CANCELLED` status, the containing block will be set to fail, and all other nodes which have not yet finished will be set to `CANCELLED` status (those nodes will be rolled back if they're in the middle of their deploying process). Consequently, all blocks after that failed block will be set to `CANCELLED` status and be stopped.
 
 ## Console view
 

docs/content/en/docs-dev/user-guide/managing-application/rolling-back-a-deployment.md

@@ -7,7 +7,7 @@ description: >
 ---
 
 Rolling back a deployment can be automated by enabling the `autoRollback` field in the application configuration of the application. When `autoRollback` is enabled, the deployment will be rolled back if any of the following conditions are met:
-- a stage of the deployment pipeline was failed
+- a stage of the deployment pipeline has failed
 - an analysis stage determined that the deployment had a negative impact
 - any error occurs while deploying
 

docs/content/en/docs-dev/user-guide/managing-application/secret-management.md

@@ -6,7 +6,7 @@ description: >
   Storing secrets safely in the Git repository.
 ---
 
-When doing GitOps, user wants to use Git as a single source of truth. But storing credentials like Kubernetes Secret or Terraform's credentials directly in Git is not safe.
+When doing GitOps, users want to use Git as a single source of truth. But storing credentials like Kubernetes Secret or Terraform's credentials directly in Git is not safe.
 This feature helps you keep that sensitive information safely in Git, right next to your application manifests.
 
 Basically, the flow will look like this:
@@ -88,7 +88,7 @@ Any file in the application directory can use `.encryptedSecrets` context to acc
 
 For example,
 
-- Accessing by a Kubernets Secret manfiest
+- Accessing by a Kubernetes Secret manifest
 
 ``` yaml
 apiVersion: v1
@@ -99,7 +99,7 @@ data:
   password: "{{ .encryptedSecrets.password }}"
 ```
 
-- Configuring ENV variable of a Lambda function to use a encrypted secret
+- Configuring ENV variable of a Lambda function to use an encrypted secret
 
 ``` yaml
 apiVersion: pipecd.dev/v1beta1
@@ -110,7 +110,7 @@ spec:
     KEY: "{{ .encryptedSecrets.key }}"
 ```
 
-In all cases, `Piped` will decrypt the encrypted secrets and render the decryption target files before using to handle any deployment tasks.
+In all cases, `Piped` will decrypt the encrypted secrets and render the decryption target files before using them to handle any deployment tasks.
 
 ## Examples
 

docs/content/en/docs-dev/user-guide/managing-application/triggering-a-deployment.md

@@ -22,9 +22,9 @@ Configuration for the trigger used to determine whether we trigger a new deploym
 
 See [Configuration Reference](../../configuration-reference/#deploymenttrigger) for the full configuration.
 
-After a new deployment was triggered, it will be queued to handle by the appropriate `piped`. And at this time the deployment pipeline was not decided yet.
+After a new deployment is triggered, it will be queued to be handled by the appropriate `piped`. At this time, the deployment pipeline has not been decided yet.
 `piped` schedules all deployments of applications to ensure that for each application only one deployment will be executed at the same time.
-When no deployment of an application is running, `piped` picks queueing one to plan the deploying pipeline.
+When no deployment of an application is running, `piped` picks a queued one to plan the deploying pipeline.
 `piped` plans the deploying pipeline based on the application configuration and the diff between the running state and the specified state in the newest commit.
 For example:
 
@@ -33,7 +33,7 @@ For example:
 
 You can force `piped` planner to decide to use the [QuickSync](../../../concepts/#sync-strategy) or the specified pipeline based on the commit message by configuring [CommitMatcher](../../configuration-reference/#commitmatcher) in the application configuration.
 
-After being planned, the deployment will be executed as the decided pipeline. The deployment execution including the state of each stage as well as their logs can be viewed in realtime at the deployment details page.
+After being planned, the deployment will be executed as the decided pipeline. The deployment execution including the state of each stage as well as their logs can be viewed in real time on the deployment details page.
 
 ![](/images/deployment-details.png)
 <p style="text-align: center;">

docs/content/en/docs-dev/user-guide/managing-controlplane/adding-a-project.md

@@ -8,7 +8,7 @@ description: >
 
 The control plane ops can add a new project for a team.
 Project adding can be simply done from an internal web page prepared for the ops.
-Because that web service is running in an `ops` pod, so in order to access it, using `kubectl port-forward` command to forward a local port to a port on the `ops` pod as following:
+Because that web service is running in an `ops` pod, in order to access it, use the `kubectl port-forward` command to forward a local port to a port on the `ops` pod as follows:
 
 ``` console
 kubectl port-forward service/pipecd-ops 9082 --namespace={NAMESPACE}
@@ -21,4 +21,4 @@ Registering a new project requires only a unique ID string and an optional descr
 
 Once a new project has been registered, a static admin (username, password) will be automatically generated for the project admin. You can send that information to the project admin. The project admin first uses the provided static admin information to log in to PipeCD. After that, they can change the static admin information, configure the SSO, RBAC or disable static admin user.
 
-__Caution:__ The Role-Based Access Control (RBAC) setting is required to enable your team login using SSO, please make sure you have that setup before disable static admin user.
+__Caution:__ The Role-Based Access Control (RBAC) setting is required to enable your team to log in using SSO. Please make sure you have that set up before disabling the static admin user.

docs/content/en/docs-dev/user-guide/managing-controlplane/auth.md

@@ -44,8 +44,8 @@ PipeCD supports any OIDC provider, with tested providers including Keycloak, Aut
 Requirements and Troubleshooting:
 
 - The OIDC provider must provide claims for user's roles and username.
-- Roles claim value must use same values as pre-configured project RBAC Roles.
-- - Claims can be retreived from the IdToken or UserInfo endpoint. The UserInfo endpoint will be used if issuer supports it.
+- Roles claim value must use the same values as pre-configured project RBAC Roles.
+- Claims can be retrieved from the IdToken or UserInfo endpoint. The UserInfo endpoint will be used if the issuer supports it.
 - You can use set a custom claim key name for roles and username in the OIDC provider. Using `usernameClaimKey` and `rolesClaimKey` in the configuration. If not set, the default value will be chosen in the following order:
 
   - Supported Claims Key for Username (in order of priority): `username`, `preferred_username`,`name`, `cognito:username`

docs/content/en/docs-dev/user-guide/managing-controlplane/registering-a-piped.md

@@ -6,7 +6,7 @@ description: >
   This page describes how to register a new piped to a project.
 ---
 
-The list of pipeds are shown in the Settings page. Anyone who has the project admin role can register a new piped by clicking on the `+ADD` button.
+The list of pipeds is shown on the Settings page. Anyone who has the project admin role can register a new piped by clicking on the `+ADD` button.
 
 <br>