Fix syntax errors in the document

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

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

17 files changed, 40 insertions, 40 deletions

diff --git a/ADOPTERS.md b/ADOPTERS.md
index 974e67d56..cfa107bf7 100644
--- a/ADOPTERS.md
+++ b/ADOPTERS.md
@@ -16,7 +16,7 @@ KubeEdge is used by many companies. If you are using KubeEdge in your organizati
 
 #### Challenge
 
-It is an important demand for the manufactory of Raisecom Technology to ensure the industrial production safety. Traditional workers’ production safety was detected manually, which was slow and inefficient. The situation that workers did not obey the safety requirements still happened and it could be ignored sometimes, which could generate great safety risks and affect the production efficiency of the factory.
+It is an important demand for the manufactory of Raisecom Technology to ensure the industrial production safety. Traditional workers’ production safety was detected manually, which was slow and inefficient. The situation that workers did not obey the safety requirements still happened, and it could be ignored sometimes, which could generate great safety risks and affect the production efficiency of the factory.
 
 
 
@@ -65,7 +65,7 @@ Jingying Shuzhi Technology Co., Ltd worked with KubeEdge to develop the Mine Bra
 + Service instances can recover automatically and run normally even if edge nodes are disconnected from the cloud, so the system is more reliable.
 + Edge intelligence, powerful computing, and management of a massive number of edge devices makes precise audio and video recognition possible for a range of different scenarios.
 
-With a foundation based on years of accumulated experience, Jingying Shuzhi Technology Co., Ltd has developed the ability to handle many different AI scenarios and cloud-edge-device O&M, effectively ensuring reliable services and precise recognition.
+With a foundation based on years of accumulated experience, Jingying Shuzhi Technology Co., Ltd has developed the ability to handle many AI scenarios and cloud-edge-device O&M, effectively ensuring reliable services and precise recognition.
 
 ### Benefits
 With the Mine Brain solution, coal mining enterprises in Shanxi have achieved intelligent coal mining in more than 1,000 mines. AI analysis algorithms delivered from the cloud to mining sites provide real-time risk assessments with an identification rate of up to 98%. Centralized monitoring of IT infrastructure at remote sites has reduced the cost of O&M by 65%, and integrated full-stack IT devices have reduced deployment costs by 75%. The Mine Brain solution has helped the coal industry ensure safe production, and ultimately achieved intelligent upgrade for the entire industry.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index d660de857..5278455fb 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -87,7 +87,7 @@ This is a rough outline of what a contributor's workflow looks like:
 ## Creating Pull Requests
 
 Pull requests are often called simply "PR".
-KubeEdge generally follows the standard [github pull request](https://help.github.com/articles/about-pull-requests/) process.
+KubeEdge generally follows the standard [GitHub pull request](https://help.github.com/articles/about-pull-requests/) process.
 To submit a proposed change, please develop the code/fix and add new test cases.
 After that, run these local verifications before submitting pull request to predict the pass or
 fail of continuous integration.
diff --git a/README.md b/README.md
index 20e40b645..0b569cee9 100644
--- a/README.md
+++ b/README.md
@@ -53,7 +53,7 @@ KubeEdge consists of cloud part and edge part.
 - [EdgeHub](https://kubeedge.io/en/docs/architecture/edge/edgehub): a web socket client responsible for interacting with Cloud Service for the edge computing (like Edge Controller as in the KubeEdge Architecture). This includes syncing cloud-side resource updates to the edge, and reporting edge-side host and device status changes to the cloud.
 - [Edged](https://kubeedge.io/en/docs/architecture/edge/edged): an agent that runs on edge nodes and manages containerized applications.
 - [EventBus](https://kubeedge.io/en/docs/architecture/edge/eventbus): a MQTT client to interact with MQTT servers (mosquitto), offering publish and subscribe capabilities to other components.
-- [ServiceBus](https://kubeedge.io/en/docs/architecture/edge/servicebus): a HTTP client to interact with HTTP servers (REST), offering HTTP client capabilities to components of cloud to reach HTTP servers running at edge.
+- [ServiceBus](https://kubeedge.io/en/docs/architecture/edge/servicebus): an HTTP client to interact with HTTP servers (REST), offering HTTP client capabilities to components of cloud to reach HTTP servers running at edge.
 - [DeviceTwin](https://kubeedge.io/en/docs/architecture/edge/devicetwin): responsible for storing device status and syncing device status to the cloud. It also provides query interfaces for applications.
 - [MetaManager](https://kubeedge.io/en/docs/architecture/edge/metamanager): the message processor between edged and edgehub. It is also responsible for storing/retrieving metadata to/from a lightweight database (SQLite).
 
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