Update docs about user guide

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

@@ -48,6 +48,18 @@ When the deployment is success, it means the running state is synced with the de
 A `.pipe.yaml` yaml file that contains configuration data to define how to deploy the application.
 Each application has one deployment configuration file in Git repository at application directory.
 
+### Application Configuration Directory
+
+A directory in Git repository containing deployment configuration file (`.pipe.yaml`) and application manifests.
+Each application must has one application configuration directory.
+
+### Quick Sync
+
+Quick sync is a fast way to sync application to the state specified in a Git commit without any progressive strategy or manual approving. Its pipeline contains just only one `SYNC` stage. For examples:
+- quick sync a Kubernetes application is just applying all manifests
+- quick sync a Terraform application is automatically applying all detected changes
+- quick sync a CloudRun/Lambda application is rolling out the new version and routing all traffic to it
+
 ### Stage
 
 A temporary middle state between current state and desired state of a deployment process.

docs/content/en/docs/user-guide/adding-a-wait-stage.md

@@ -20,6 +20,7 @@ spec:
         with:
           duration: 5m
       - name: K8S_PRIMARY_ROLLOUT
+      - name: K8S_CANARY_CLEAN
 ```
 
 ![](/images/deployment-wait-stage.png)

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

@@ -1,12 +1,14 @@
 ---
 title: "Cancelling a deployment"
 linkTitle: "Cancelling a deployment"
-weight: 7
+weight: 8
 description: >
-  This page describes how to manually and forcely sync an application.
+  This page describes how to cancel a running deployment.
 ---
 
-> TBA
+A running deployment can be cancelled from web UI at the deployment details page.
+
+If the application rollback is enabled in the deployment configuration, the rollback process will be executed after the cancelling. You can also explicitly specify to do rollback after the cancelling or not from the web UI by clicking on `▼` mark of the `CANCEL` button to select your option.
 
 ![](/images/cancel-deployment.png)
 <p style="text-align: center;">

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

@@ -1,15 +1,15 @@
 ---
 title: "Rolling back a deployment"
 linkTitle: "Rolling back a deployment"
-weight: 8
+weight: 7
 description: >
-  Overview about deploying Kubernetes application.
+  This page describes when a deployment is rolled back automatically and how to manually rollback a deployment.
 ---
 
 > TBA
 
-![](/images/cancel-deployment.png)
+![](/images/rolled-back-deployment.png)
 <p style="text-align: center;">
-Cancel a deployment with rolling back
+A deployment was rolled back
 </p>
 

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

@@ -6,10 +6,34 @@ description: >
   This page describes when a deployment is trigerred automatically and how to manually trigger a deployment.
 ---
 
-> TBA
+PipeCD is using Git as a single source of truth, all application resources and infrastructure changes should be done by making a pull request to Git.
+The mission of the deployments is syncing all running resources/components of applications in the cluster to the state specified in the newest commit.
+So by default, when a new merged pull request touches an application, a new deployment for that application will be triggered to sync the application to the state specified in the newest merged commit.
 
-- Automatically syncing by Git event.
-- Manually syncing from Web UI.
+A pull request (commit) is considered as touching an application whenever its changes include:
+- one or more files inside the application configuration directory
+- one or more files inside one of the [dependencies](http://localhost:1313/docs/user-guide/configuration-reference/#kubernetesdeploymentinput) of the application
+
+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.
+`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 one queueing deployment for that application to plan the deploying pipeline.
+`piped` plans the deploying pipeline based on the deployment configuration and the diff between the running state and the specified state in the newest commit.
+For example:
+
+- when the merged pull request updated a Deployment's container image or updated a mounting ConfigMap or Secret, `piped` planner will decide that the deployment should use the specified pipeline to do a progressive deployment.
+- when the merged pull request just updated the `replicas` number, `piped` planner will decide to use a quick sync to scale the resources.
+
+You can force `piped` planer to decide to use the [QuickSync](docs/concepts/#quick-sync) or the specified pipeline based on the commit message by configuring [CommitMatcher](/docs/user-guide/configuration-reference/#commitmatcher) in the deployment 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.
+
+![](/images/deployment-details.png)
+<p style="text-align: center;">
+A Running Deployment at the Deployment Details Page
+</p>
+
+As explained above, by default all deployments will be triggered automatically by checking the merged commits but you also can manually trigger a new deployment from web UI.
+By clicking on `SYNC` button at the application details page, a new deployment for that application will be triggered to sync the application to be the state specified at the newest commit of the master branch (default branch).
 
 ![](/images/application-details.png)
 <p style="text-align: center;">