Fix syntax errors in the document

Signed-off-by: Fish-pro <zechun.chen@daocloud.io>

Co-authored-by: Fisher Xu <xufei40@huawei.com>

14 files changed, 36 insertions, 36 deletions

diff --git a/docs/proposals/EdgeSite.md b/docs/proposals/EdgeSite.md
index 32fbbf08d..bf591c874 100644
--- a/docs/proposals/EdgeSite.md
+++ b/docs/proposals/EdgeSite.md
@@ -27,7 +27,7 @@ There are scenarios users need to run a standalone Kubernetes cluster at edge to
 
   In some IOT scenarios, users need to deploy a full control edge environment and running offline.
 
-For these use cases, a standalone, full controlled, light weight Edge cluster is required.
+For these use cases, a standalone, full controlled, lightweight Edge cluster is required.
 By integrating KubeEdge and standard Kubernetes, this proposal enables customers to run an efficient kubernetes cluster for Edge/IOT computing. User can also leverage other smaller Kubernetes implementation such as K3S to make the footprint even smaller.
 
 ## Assumptions
@@ -46,7 +46,7 @@ The assumptions are
 With the integration, the following can be enabled
 
 1. Full control of Kubernetes cluster at edge
-2. Light weight control plane and agent
+2. Lightweight control plane and agent
 3. Edge worker node autonomy in case of network disconnection/reconnection
 4. All benefits of edge computing including latency, data locality, etc.
 
diff --git a/docs/proposals/cloud-edge-custom-message-design.md b/docs/proposals/cloud-edge-custom-message-design.md
index e62cc15e4..503924dec 100644
--- a/docs/proposals/cloud-edge-custom-message-design.md
+++ b/docs/proposals/cloud-edge-custom-message-design.md
@@ -16,7 +16,7 @@ This proposal addresses this problem for users to delivery their custom messages
 
 ## Proposal
 
-Currently There is no common solutions to deliver user's custom messages between cloud and edge.
+Currently, there is no common solutions to deliver user's custom messages between cloud and edge.
 The proposal is to introduce a solution for users to deliver their custom message between cloud and edge by rest api or mqtt broker.
 
 ### Usage scenarios
diff --git a/docs/proposals/cloudcore-ha-design.md b/docs/proposals/cloudcore-ha-design.md
index 1142ce4c4..90bf4a865 100644
--- a/docs/proposals/cloudcore-ha-design.md
+++ b/docs/proposals/cloudcore-ha-design.md
@@ -67,7 +67,7 @@ At present, CloudCore is essentially an edge-resource distribution center, which
   1. LocationCache
   2. sync-CRD in etcd
 
-  For the former, CloudCore will trigger the initialization of LocationCache when restarts; For the latter, CloudCore crash does not affect information in etcd. Messages left out during crash will be re-sync when SyncController reruns.
+  For the former, CloudCore will trigger the initialization of LocationCache when restarts; For the latter, CloudCore crash does not affect information in etcd. Messages left out during crash will be re-synced when SyncController reruns.
 
 ### HA in hot standby mode
 #### The lifecycle of CloudCore
diff --git a/docs/proposals/configuration.md b/docs/proposals/configuration.md
index e48617c2b..4839e10b7 100644
--- a/docs/proposals/configuration.md
+++ b/docs/proposals/configuration.md
@@ -55,7 +55,7 @@ We recommend referring to the kubernetes component config api design to redesign
 
 ## Goals
 
-* KubeEdge components use one configuration file instead of the original 3 configuration files. It support json or yaml format, defaut is yaml.
+* KubeEdge components use one configuration file instead of the original 3 configuration files. It supports json or yaml format, defaut is yaml.
 
 * Start the KubeEdge component with the --config flag, this flag set to the path of the component's config file. The component will then load its config from this file, if --config flag not set, component will read a default configuration file.
 
@@ -1198,7 +1198,7 @@ In order to support the old configuration file , there are 2 options:
 
 We use the second option, because:
 
-* There are 3 old configuration files for each component, it is quite different from the new configuration definition and they are eventually discarded in the near future.
+* There are 3 old configuration files for each component, it is quite different from the new configuration definition, and they are eventually discarded in the near future.
 
 * If the component supports the old configuration file, it will add configuration-compatible logic inside the component. We might as well let keadm do this. such as:
 
diff --git a/docs/proposals/cri.md b/docs/proposals/cri.md
index 24945176f..17e08cc68 100644
--- a/docs/proposals/cri.md
+++ b/docs/proposals/cri.md
@@ -33,7 +33,7 @@ status: implementable
 
 ## Motivation
 This proposal addresses the Container Runtime Interface support in edged to enable the following
-1. Support light weight container runtimes on resource constrained edge node which are unable to run the existing docker runtime
+1. Support lightweight container runtimes on resource constrained edge node which are unable to run the existing docker runtime
 2. Support multiple container runtimes like docker, containerd, cri-o etc on the edge node.
 
 ### Goals
@@ -47,9 +47,9 @@ CRI support in edged must:
 
 ## Proposal
 
-Currently Kubernetes kubelet CRI supports container runtimes like containerd, cri-o etc and support for docker runtime is
-provided using dockershim as well. However going forward even docker runtime will be supported through only CRI. However
-currently kubeedge edged supports only docker runtime using the legacy dockertools. Hence we propose to support multiple
+Currently, Kubernetes kubelet CRI supports container runtimes like containerd, cri-o etc. and support for docker runtime is
+provided using dockershim as well. However, going forward even docker runtime will be supported through only CRI. However,
+currently kubeedge edged supports only docker runtime using the legacy dockertools. Hence, we propose to support multiple
 container runtime in kubeedge edged as follows
 1. Include CRI support as in kubernetes kubelet to support contianerd, cri-o etc
 2. Continue with docker runtime support using legacy dockertools until CRI support for the same is available i.e. support
@@ -58,7 +58,7 @@ for docker runtime using dockershim is not considered in edged
 
 ### Use Cases
 
-* Customer can run light weight container runtime on resource constrained edge node that cannot run the existing docker runtime
+* Customer can run lightweight container runtime on resource constrained edge node that cannot run the existing docker runtime
 * Customer has the option to choose from multiple container runtimes on his edge platform
 
 
@@ -113,8 +113,8 @@ type edged struct {
 ###  Edged object creation modifications
 
 The existing newEdged() function needs to modified include creating CRI runtime object based on the runtime type including
-creations of objects for runtime and image services. However the existing edged does not provide the support for all the
-parameters required to create the CRI runtime object and default parameters need to be considered for the same like Image GC manager, Container GC manager, Volume manager and container lifecycle manager (clcm)
+creations of objects for runtime and image services. However, the existing edged does not provide the support for all the
+parameters required to create the CRI runtime object and default parameters need to be considered for the same as Image GC manager, Container GC manager, Volume manager and container lifecycle manager (clcm)
 
 ```go
 
@@ -156,7 +156,7 @@ func getRuntimeAndImageServices(remoteRuntimeEndpoint string, remoteImageEndpoin
        Initialize Remote Image Service
  }
 ```
-The function to read the configuration needs to be modified to include the parameters required for remote runtime. By default
+The function to read the configuration needs to be modified to include the parameters required for remote runtime. By default,
 docker runtime shall be used and also default values for the parameters need to be provided if the parameters are not provided
 in the configuration file.
 
diff --git a/docs/proposals/device-management-enhance.md b/docs/proposals/device-management-enhance.md
index 0c2d37105..439bb4994 100644
--- a/docs/proposals/device-management-enhance.md
+++ b/docs/proposals/device-management-enhance.md
@@ -38,7 +38,7 @@ We propose below modifications on current design.
 * Add customized protocol config in device CRD.
 * Add common part in protocol config section
 * Extract common part of Modbus protocol config into an independent common part.
-* Allow add any customized K-V in protocol config and property visitor section.
+* Allow to add any customized K-V in protocol config and property visitor section.
 * Support using boolean, float, double and bytes to describe type of property in device model.
 
 
@@ -47,14 +47,14 @@ We propose below modifications on current design.
 
 * Reuse device model.
   * Considering device properties are physical attributes, but property visitors are manually configured attributes. Combining device properties and property visitors in device model decrease the reusability of device model.
-  * Case 1: Same devices are connected to a central management server, eg. SCADA. In this case, devices have same properties but different property visitors.
+  * Case 1: Same devices are connected to a central management server, e.g. SCADA. In this case, devices have same properties but different property visitors.
   * Case 2: Same devices are using different industrial protocol. In this case, devices have same properties but different property visitors.
 * Customized data collect cycle and report cycle
    * Users can define collect cycle and report cycle to each property. For example, a temperature property may need be collected per second, while a throughput property may need be collected per hour.
 * Deal data of non-twin properties.
   * Currently, only twin properties will be sync between edge and cloud. Non-twin properties are not processed by edge-core. Time-Serial data are produced from devices and should have a way to allow user deal with these data.
 * Deal various industrial protocols
-  * Currently, only Modbus, OPC-UA and bluetooth are supported by KubeEdge. However there are thousands of industrial protocols. It is impossible to define all these protocols in KubeEdge. If users want to use these un-predefined protocols, we should provide a way to support.
+  * Currently, only Modbus, OPC-UA and bluetooth are supported by KubeEdge. However, there are thousands of industrial protocols. It is impossible to define all these protocols in KubeEdge. If users want to use these un-predefined protocols, we should provide a way to support.
 * Customized provided protocol
   * If users want to add some special control value, such as bulk related collection, in provided protocol like Modbus, he can use the customized K-V features.
 
diff --git a/docs/proposals/edgemesh-design.md b/docs/proposals/edgemesh-design.md
index d1ec431d5..86c29f73a 100644
--- a/docs/proposals/edgemesh-design.md
+++ b/docs/proposals/edgemesh-design.md
@@ -25,9 +25,9 @@ The cloud native and microservice architecture is becoming more and more popular
 ## Constraints and Assumptions
 1. No DNS services available for edge.
 2. The identification and authentication should be handled by microservices.
-3. When service communication between edge to edge, they may work offline. With the purpose to deliver a "expected result" to the user system, the service definition should be pushed down to the edge right after the definition operation. That is to say, the istio model may not be suitable for edge, in istio model, the service definition is pulled from K8S master when the service is invoked.
+3. When service communication between edge to edge, they may work offline. With the purpose to deliver an "expected result" to the user system, the service definition should be pushed down to the edge right after the definition operation. That is to say, the istio model may not be suitable for edge, in istio model, the service definition is pulled from K8S master when the service is invoked.
 4. Only support HTTP communication in the first step
-5. All edge nodes are in the same sub-network and they have the network reachability.
+5. All edge nodes are in the same subnetwork, and they have the network reachability.
 
 ## Use cases
 <img src="../images/proposals/service-design.png">
@@ -85,7 +85,7 @@ Add two endpoints definition:
 * R4: Users/Applications create a request.
 * R5: Router receives the request and forwards it to the target based on rule.
 
-Since Router fetches rules from DB, in later versions it can be started as a different process than edge-controller. Also it enables router to retrieve all the rules after process restarts.
+Since Router fetches rules from DB, in later versions it can be started as a different process than edge-controller. Also, it enables router to retrieve all the rules after process restarts.
 ### Router Low-level Design
 
 ### Providers
diff --git a/docs/proposals/keadm-debug.md b/docs/proposals/keadm-debug.md
index b0c082e34..e0d34231e 100644
--- a/docs/proposals/keadm-debug.md
+++ b/docs/proposals/keadm-debug.md
@@ -220,10 +220,10 @@ Flags:
        1. check system resources is enough
        2. check container runtime is running
        3. check all edgecore components are running
-       4. check all database is exist
+       4. check all database is existed
        5. confirm that the configuration file exists
        6. check cloudercore can be connected
-    3. Use command `pod` can troubleshooting specific container application instances on nodes
+    3. Use command `pod` can troubleshoot specific container application instances on nodes
        1. check node status
        2. check pod msg in database
        3. check pod status and containerStatus and print key messages
@@ -233,7 +233,7 @@ Flags:
 
 - What is it?
 
-  - This command will be check whether the system specific items meet the requirements of edgecore installation and operation.
+  - This command will be checked whether the system specific items meet the requirements of edgecore installation and operation.
 
 - What shall be its scope ?
   1. Check items include hardware resources or operating system resources (cpu, memory, disk, network, pid limit,etc.)
diff --git a/docs/proposals/keadm-scope.md b/docs/proposals/keadm-scope.md
index 12ac53a69..c00215d5a 100644
--- a/docs/proposals/keadm-scope.md
+++ b/docs/proposals/keadm-scope.md
@@ -14,14 +14,14 @@ last-updated: 2019-05-20
 
 # Motivation
 
-Many users shared their feedback that kubeEdge installation is too complicated and it may prevent people from trying kubeEdge. There should a simplified way to have **Getting Started with KubeEdge**, so that user can concentrate more on using it instantly, rather than
+Many users shared their feedback that kubeEdge installation is too complicated, and it may prevent people from trying kubeEdge. There should a simplified way to have **Getting Started with KubeEdge**, so that user can concentrate more on using it instantly, rather than
 getting entangled in the installation steps.
 
 # Proposal
 
 KubeEdge shall have simple commands and steps to bring up both cloud and edge components.
 The user experience in **Getting Started with KubeEdge** will be seamless.
-Hence proposing the following commands for KubeEdge installation process.
+Hence, proposing the following commands for KubeEdge installation process.
 
 ## Inscope
 
@@ -200,7 +200,7 @@ Flags:
      * This command will be responsible to bring up KubeEdge cloud components like edge-controller and K8S (using kubeadm)
 
   - What shall be its scope ?
-    1. Check version of OS and install subsequently the required pre-requisites using supported steps. Currently we will support **ONLY** (Ubuntu & CentOS)
+    1. Check version of OS and install subsequently the required pre-requisites using supported steps. Currently, we will support **ONLY** (Ubuntu & CentOS)
     2. Check and install all the pre-requisites before executing edge-controller, which are
         * docker (currently 18.06.0ce3-0~ubuntu) and check if service is up
         * kubelet, kubeadm & kubectl (latest version)
@@ -236,11 +236,11 @@ Flags:
 
   - What shall be its scope ?
 
-    1. Check version of OS and install subsequently the required pre-requisites using supported steps. Currently we will support **ONLY** (Ubuntu & CentOS)
+    1. Check version of OS and install subsequently the required pre-requisites using supported steps. Currently, we will support **ONLY** (Ubuntu & CentOS)
     2. Check and install all the pre-requisites before executing edge-controller, which are
         * Docker (currently 18.06.0ce3-0~ubuntu) and check if service is up.
         * mosquitto (latest available in OS repos) and check if running.
-    3. This command will take `--certPath` (string type) as mandatory option which shall be the certificates path; wherein the certs were transferred from cloud node and uncompressed. It will modify `$GOPATH/src/github.com/kubeedge/kubeedge/edge/conf/edge.yaml` file against `edgehub.websocket.certfile` and `edgehub.websocket.keyfile` fields.
+    3. This command will take `--certPath` (string type) as mandatory option which shall be the certificates' path; wherein the certs were transferred from cloud node and uncompressed. It will modify `$GOPATH/src/github.com/kubeedge/kubeedge/edge/conf/edge.yaml` file against `edgehub.websocket.certfile` and `edgehub.websocket.keyfile` fields.
     4. Create `$GOPATH/src/github.com/kubeedge/kubeedge/build/node.json` and apply it using `curl` command to api-server
     5. This command will take mandatory `-e` or `--cloudcoreip` flag to specify the address of KubeEdge cloudcore
     6. Create `$GOPATH/src/github.com/kubeedge/kubeedge/edge/conf/edge.yaml`
diff --git a/docs/proposals/mapper-design-v2.md b/docs/proposals/mapper-design-v2.md
index 0da7bb5d5..8970f2e20 100644
--- a/docs/proposals/mapper-design-v2.md
+++ b/docs/proposals/mapper-design-v2.md
@@ -26,7 +26,7 @@ One mapper is for one type of device and could control multiple devices simultan
 The first step to control a device is to configure the device model and device instance. After that, a configmap is generated([configmap example](https://github.com/kubeedge/kubeedge/blob/master/docs/proposals/device-management-enhance.md)). Mapper will parse the configmap when starting.
 At run time, the configuration could be changed and the configmap will follow the change, device twin will also send out changing messages.
 
-About the device control/data, there're three types:
+About the device control/data, there are three types:
 
 1. Twin value. 
 ```json
diff --git a/docs/proposals/mapper-design.md b/docs/proposals/mapper-design.md
index 86f0e6f7a..acde03a99 100644
--- a/docs/proposals/mapper-design.md
+++ b/docs/proposals/mapper-design.md
@@ -32,12 +32,12 @@ Mapper is an application that is used to connect and control devices. Following
 6) Schedule actions on the device.
 7) Check health of the device.
 
-Mapper can be specific to a protocol where standards are defined i.e Bluetooth, Zigbee, etc or specific to a device if it a custom protocol.
+Mapper can be specific to a protocol where standards are defined i.e. Bluetooth, Zigbee, etc. or specific to a device if it is a custom protocol.
 
 ## Motivation
 All devices can be connected and controlled by drivers provided by their vendor.
 But the message from the device need to be translated into a format understood by KubeEdge.
-Also there should be a way to control the devices from the platform. Mapper is the application that interfaces between KubeEdge and devices.
+Also, there should be a way to control the devices from the platform. Mapper is the application that interfaces between KubeEdge and devices.
 There should be a standard design for mappers supported by KubeEdge for keeping them generic and easy to use.
 
 ### Goals
@@ -110,7 +110,7 @@ c) To report the actual state of twin attributes.
 
 **4) Data-Converter**: Data received from the devices can be in complex formats. eg: HexDecimal with bytes shuffled. This data cannot be directly understood by KubeEdge.
 The responsibility of data-converter is the convert the readings into a format understood by KubeEdge.
-Many protocols have a standard defined for the reading returned by the device. Hence a common/configurable logic can be used.
+Many protocols have a standard defined for the reading returned by the device. Hence, a common/configurable logic can be used.
 
 **5) Health-Checker**: Health-Checker can be used to periodically report the state of the device to KubeEdge.
 This can be an optional component as not all devices support health-checking. In-future can be extended to report battery-state, malfunctioning when kubeedge supports these attributes.
diff --git a/docs/proposals/node-group-management.md b/docs/proposals/node-group-management.md
index 3237a87ad..a3985fbf8 100644
--- a/docs/proposals/node-group-management.md
+++ b/docs/proposals/node-group-management.md
@@ -57,7 +57,7 @@ However, with the number of locations increasing, operation and maintenance of a
 ### Architecture
 ![image](../images/node-group-management/group-management-arch.png)
 
-The implementation consists of two components. a new `GroupManagementControllerManager` and the endpointslice filter in the `cloudcore`. The `GroupManagementControllerManager` contains controllers of new CRDs, including `NodeGroupController` and `EdgeApplicationController`. The endpointslice filter is used to filter endpoints in endpointslices before sending them to the edgecore so as to make edgecore only aware of the endpoints in the same node group.
+The implementation consists of two components. a new `GroupManagementControllerManager` and the endpointslice filter in the `cloudcore`. The `GroupManagementControllerManager` contains controllers of new CRDs, including `NodeGroupController` and `EdgeApplicationController`. The endpointslice filter is used to filter endpoints in endpointslices before sending them to the edgecore to make edgecore only aware of the endpoints in the same node group.
 
 NodeGroup will organize nodes according to their labels which should be set based on their locations in advance, `location: hangzhou` and `location: beijing` in this case. After applying the NodeGroup resource, nodes will be grouped in `hangzhou` and `beijing` logically.
 
diff --git a/docs/proposals/reliable-message-delivery.md b/docs/proposals/reliable-message-delivery.md
index c092e1877..3d5580aca 100644
--- a/docs/proposals/reliable-message-delivery.md
+++ b/docs/proposals/reliable-message-delivery.md
@@ -35,7 +35,7 @@ This proposal addresses this problem thus improve the reliable message delivery.
 
 ## Proposal
 
-Currently all the messages from the controllers go via the channel queue (which uses beehive context for messaging)
+Currently, all the messages from the controllers go via the channel queue (which uses beehive context for messaging)
 to the cloudhub. The cloudhub then uses the configured protocol server (websocket/quic) to send the data to edge nodes.
 The proposal is to introduce the node level sending message queues in cloudhub, and use the ACK message
 returned from edge nodes to ensure the message delivery is in a reliable fashion.
@@ -60,7 +60,7 @@ There are three types of message delivery mechanisms:
 The existing implementation (without this proposal) in KubeEdge is
 the first approach “At-Most-Once”, which is unreliable.
 
-The second approach “Exactly-Once” is very expensive and exhibits worst performance
+The second approach “Exactly-Once” is very expensive and exhibits the worst performance, 
 although it provides guaranteed delivery with no message loss or duplication.
 Since KubeEdge follows Kubernetes’ eventual consistency design principles,
 it is not a problem for the edge to receive the same message repeatedly, as long as message is the latest one.
diff --git a/docs/proposals/web-hook.md b/docs/proposals/web-hook.md
index 86adf0be1..56e49e05d 100644
--- a/docs/proposals/web-hook.md
+++ b/docs/proposals/web-hook.md
@@ -94,7 +94,7 @@ Webhooks: []admissionregistrationv1beta1.ValidatingWebhook{
 ```
 
 ## Resource validation
-The validation logic is registered as an http handler which responds to a specific HTTP request, each resource should have its own handler
+The validation logic is registered as a http handler which responds to a specific HTTP request, each resource should have its own handler
 pre-registered, and the validation is done by the handler.
 
 ```golang