Docs: fix grammar issues (#2303)

* fixes typos in docs

* Update edgesite.md

* fix grammar issues in docs

* fix grammar issues in docs

Co-authored-by: Jiayi Suo <joy@Jiayis-MacBook-Pro.local>

10 files changed, 18 insertions, 18 deletions

diff --git a/docs/components/beehive.md b/docs/components/beehive.md
index 509a4af15..b8762af82 100644
--- a/docs/components/beehive.md
+++ b/docs/components/beehive.md
@@ -42,7 +42,7 @@ Message has 3 parts
 
 ### (_Important for understanding beehive operations_)
 
-1. **channels:** channels is a map of string(key) which is name of module and chan(value) of message which will used to send message to the respective module.
+1. **channels:** channels is a map of string(key) which is name of module and chan(value) of message which will be used to send message to the respective module.
 2. **chsLock:** lock for channels map
 3. **typeChannels:** typeChannels is a map of string(key)which is group name and (map of string(key) to chan(value) of message ) (value) which is map of name of each module in the group to the channels of corresponding module.
 4. **typeChsLock:** lock for typeChannels map
diff --git a/docs/components/cloud/cloudhub.md b/docs/components/cloud/cloudhub.md
index c74dc68ee..b73a5e3bb 100644
--- a/docs/components/cloud/cloudhub.md
+++ b/docs/components/cloud/cloudhub.md
@@ -32,7 +32,7 @@ Event object is then passed through the channel.
 - TLS certificates are loaded through the path provided in the context object
 - HTTP server is started with TLS configurations
 - Then HTTP connection is upgraded to websocket connection receiving conn object.
-- ServeConn function the serves all the incoming connections
+- ServeConn function serves all the incoming connections
 
 ### Read message from edge:
 
diff --git a/docs/components/edge/devicetwin.md b/docs/components/edge/devicetwin.md
index 66201ae4f..35bb1b910 100644
--- a/docs/components/edge/devicetwin.md
+++ b/docs/components/edge/devicetwin.md
@@ -106,7 +106,7 @@ deleted and also updates the devices that were already existing in the database
 - The eventbus module receives the message that arrives on the subscribed topic,the message is then forwarded  to the
 devicetwin controller which further forwards it to the membership module.
 - The membership  module adds devices that are mentioned in the message, removes
-devices that that are not present in the cache.
+devices that are not present in the cache.
 - After updating the details of the devices a  message is sent to the communication module of the device twin.
 
   ![Membership Detail](../../images/devicetwin/membership-detail.png)
diff --git a/docs/components/edge/edged.md b/docs/components/edge/edged.md
index 05cd52e4b..ff339facf 100644
--- a/docs/components/edge/edged.md
+++ b/docs/components/edge/edged.md
@@ -68,7 +68,7 @@ The flow diagram below explains the message flow.
 
 *Fig 7: Secret Message Handling at EdgeD*
 
-Edged uses the MetaClient module to fetch secrets from MetaManager. If edged queries for a new secret which is not yet stored in MetaManager, the request is forwarded to the Cloud. Before sending the response containing the secret, MetaManager stores it in a local database. Subsequent queries for the same secret key will be retrieved from the database, reducing latency. The flow diagram below shows how a secret is fetched from MetaManager and the Cloud. It also descibes how the secret is stored in MetaManager.
+Edged uses the MetaClient module to fetch secrets from MetaManager. If edged queries for a new secret which is not yet stored in MetaManager, the request is forwarded to the Cloud. Before sending the response containing the secret, MetaManager stores it in a local database. Subsequent queries for the same secret key will be retrieved from the database, reducing latency. The flow diagram below shows how a secret is fetched from MetaManager and the Cloud. It also describes how the secret is stored in MetaManager.
 
 ![Query Secret](../../images/edged/query-secret-from-edged.png)
 
@@ -89,7 +89,7 @@ The flow diagram below explains the message flow.
 
 *Fig 9: ConfigMap Message Handling at EdgeD*
 
-Edged uses the MetaClient module to fetch ConfigMaps from MetaManager. If edged queries for a new ConfigMap which is not yet stored in MetaManager, the request is forwarded to the Cloud. Before sending the response containing the ConfigMap, MetaManager stores it in a local database. Subsequent queries for the same ConfigMap key will be retrieved from the database, reducing latency. The flow diagram below shows how ConfigMaps are fetched from MetaManager and the Cloud. It also descibes how ConfigMaps are stored in MetaManager.
+Edged uses the MetaClient module to fetch ConfigMaps from MetaManager. If edged queries for a new ConfigMap which is not yet stored in MetaManager, the request is forwarded to the Cloud. Before sending the response containing the ConfigMap, MetaManager stores it in a local database. Subsequent queries for the same ConfigMap key will be retrieved from the database, reducing latency. The flow diagram below shows how ConfigMaps are fetched from MetaManager and the Cloud. It also describes how ConfigMaps are stored in MetaManager.
 
 ![Query Configmaps](../../images/edged/query-configmap-from-edged.png)
 
@@ -120,7 +120,7 @@ Status manager is an independent edge routine, which collects pods statuses ever
 
 Volume manager runs as an edge routine which brings out the information of which volume(s) are to be attached/mounted/unmounted/detached based on pods scheduled on the edge node.
 
-Before starting the pod, all the specified volumes referenced in pod specs are attached and mounted, Till then the flow is blocked and with it other operations.
+Before starting the pod, all the specified volumes referenced in pod specs are attached and mounted, Till then the flow is blocked and with its other operations.
 
 ## MetaClient
 
diff --git a/docs/components/edge/edgehub.md b/docs/components/edge/edgehub.md
index 44afced29..5515ac573 100644
--- a/docs/components/edge/edgehub.md
+++ b/docs/components/edge/edgehub.md
@@ -23,7 +23,7 @@ A keep-alive message or heartbeat is sent to cloudHub after every heartbeatPerio
 
 ## Publish Client Info
 
-- The main responsibility of publish client info is to inform the other groups or modules regarding the status of connection to the cloud.
+- The main responsibility of publishing client info is to inform the other groups or modules regarding the status of connection to the cloud.
 
 - It sends a beehive message to all groups (namely metaGroup, twinGroup and busGroup), informing them whether cloud is connected or disconnected.
 
diff --git a/docs/components/edgesite.md b/docs/components/edgesite.md
index a4c55565b..bda8b1a8f 100644
--- a/docs/components/edgesite.md
+++ b/docs/components/edgesite.md
@@ -10,15 +10,15 @@ EdgeSite helps running lightweight clusters at edge.
 
 ## Motivation
 
-There are scenarios user need to run a standalone Kubernetes cluster at edge to get full control and improve the offline scheduling capability. There are two scenarios user need to do that:
+There are scenarios users need to run a standalone Kubernetes cluster at edge to get full control and improve the offline scheduling capability. There are two scenarios users need to do that:
 
 * The edge cluster is in CDN instead of the user's site
 
   The CDN sites usually be large around the world and the network connectivity and quality cannot be guaranteed. Another factor is that the application deployed in CDN edge do not need to interact with center usually. For those deploy edge cluster in CDN resources, they need to make sure the cluster is workable without the connection with central cloud not only for the deployed applications but also the schedule capabilities. So that the CDN edge is manageable regardless the connection to one center.
 
-* User need to deploy an edge environment with limited resources and offline running for most of the time
+* Users need to deploy an edge environment with limited resources and offline running for most of the time
 
-  In some IOT scenarios, user need to deploy a full control edge environment and running offline.
+  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.
 By integrating KubeEdge and standard Kubernetes, this EdgeSite enables customers to run an efficient kubernetes cluster for Edge/IOT computing.
@@ -114,7 +114,7 @@ Click [here](https://github.com/kubeedge/kubeedge/releases) and download.
 
 #### Configuring EdgeSite
 
-Genarate edgesite config by `edgesite --minconfig` and update:
+Generate edgesite config by `edgesite --minconfig` and update:
 
 + Configure K8S (API Server)
 
diff --git a/docs/components/mappers/bluetooth_mapper.md b/docs/components/mappers/bluetooth_mapper.md
index eff473dfc..a495ef816 100644
--- a/docs/components/mappers/bluetooth_mapper.md
+++ b/docs/components/mappers/bluetooth_mapper.md
@@ -25,7 +25,7 @@ make bluetooth_mapper_image
 docker tag bluetooth_mapper:v1.0 <your_dockerhub_username>/bluetooth_mapper:v1.0
 docker push <your_dockerhub_username>/bluetooth_mapper:v1.0
 
-Note: Before trying to push the docker image to the remote repository please ensure that you have signed into docker from your node, if not please type the followig command to sign in
+Note: Before trying to push the docker image to the remote repository please ensure that you have signed into docker from your node, if not please type the following command to sign in
  docker login
  # Please enter your username and password when prompted
 ```
@@ -74,7 +74,7 @@ the mapper like scheduler and watcher.
 
 2. Name of each action should be unique, it is using this name that the other modules like the scheduler or watcher can invoke which action to perform.
 
-3. Perform-immediately field of the action manager tells the action manager whether it is supposed to perform the action immediately or not, if it set to true then the action manger will
+3. Perform-immediately field of the action manager tells the action manager whether it is supposed to perform the action immediately or not, if it set to true then the action manager will
 perform the event once.
 
 4. Each action is associated with a device-property-name, which is the property-name defined in the device CRD, which in turn contains the implementation details required by the action.
@@ -100,7 +100,7 @@ perform the event once.
               - ......
                 ......
 
- 1. Multiple schedules can be defined by the user by providing an array as input though the configuration file.
+ 1. Multiple schedules can be defined by the user by providing an array as input through the configuration file.
 
  2. Name specifies the name of the schedule to be executed, each schedule must have a unique name as it is used as a method of identification by the scheduler.
 
@@ -145,7 +145,7 @@ perform the event once.
 
  The controller module is responsible for exposing MQTT APIs to perform CRUD operations on the watcher, scheduler and action manager. The controller is also responsible for starting the other modules like action manager, watcher and scheduler.
  The controller first connects the MQTT client to the broker (using the mqtt configurations, specified in the configuration file), it then initiates the watcher which will connect to the device (based on the configurations provided in the configuration file) and the
- watcher runs parallelly, after this it starts the action manger which executes all the actions that have been enabled in it, after which the scheduler is started to run parallelly as well. Given below is a guide to provide input to the
+ watcher runs parallelly, after this it starts the action manager which executes all the actions that have been enabled in it, after which the scheduler is started to run parallelly as well. Given below is a guide to provide input to the
  controller through the configuration file.
 
           mqtt:
diff --git a/docs/components/mappers/modbus_mapper.md b/docs/components/mappers/modbus_mapper.md
index 52134c58b..29a52134f 100644
--- a/docs/components/mappers/modbus_mapper.md
+++ b/docs/components/mappers/modbus_mapper.md
@@ -57,7 +57,7 @@ The modbus mapper consists of the following four major modules :-
 
  ### Modbus Manager
 
- Modbus Manager is a component which can perform an read or write action on modbus device. The following are the main responsibilities of this component:
+ Modbus Manager is a component which can perform a read or write action on modbus device. The following are the main responsibilities of this component:
  a) When controller receives message of expected devicetwin value, Modbus Manager will connect to the device and change the registers to make actual state equal to expected.
 
  b) When controller checks all the properties of devices, Modbus Manager will connect to the device and read the actual value in registers according to the dpl configuration.
diff --git a/docs/configuration/cri.md b/docs/configuration/cri.md
index 94de29a6c..26c01ad4e 100644
--- a/docs/configuration/cri.md
+++ b/docs/configuration/cri.md
@@ -71,7 +71,7 @@ NOTE: since cri doesn't support multi-tenancy while `containerd` does, the names
 
 Follow the [CRI-O install guide](https://github.com/cri-o/cri-o/blob/master/tutorials/setup.md) to setup CRI-O.
 
-If your edge node is running on the ARM platform and your distro is ubuntu18.04, you might need to build the binaries form source and then install, since CRI-O packages are not available in the [Kubic](https://build.opensuse.org/project/show/devel:kubic:libcontainers:stable) repository for this combination.
+If your edge node is running on the ARM platform and your distro is ubuntu18.04, you might need to build the binaries from source and then install, since CRI-O packages are not available in the [Kubic](https://build.opensuse.org/project/show/devel:kubic:libcontainers:stable) repository for this combination.
 
 ```bash
 git clone https://github.com/cri-o/cri-o
diff --git a/docs/configuration/kubeedge.md b/docs/configuration/kubeedge.md
index 8fae49c87..6b4516870 100644
--- a/docs/configuration/kubeedge.md
+++ b/docs/configuration/kubeedge.md
@@ -79,7 +79,7 @@ In the cloudcore.yaml, modify the below settings.
 
     **Note:** If your KubeEdge version is before the v1.3, then just skip the step 3.
 
-3. Configure all the IP addresses of CloudCore which are exposed to the edge nodes(like floating IP) in the `advertiseAddress`, which will be add to SANs in cert of cloudcore.
+3. Configure all the IP addresses of CloudCore which are exposed to the edge nodes(like floating IP) in the `advertiseAddress`, which will be added to SANs in cert of cloudcore.
 
     ```yaml
     modules: