diff --git a/docs/en_us/FAQ/FAQ.md b/docs/en_us/FAQ/FAQ.md
index e64a9140..d05f2358 100644
--- a/docs/en_us/FAQ/FAQ.md
+++ b/docs/en_us/FAQ/FAQ.md
@@ -5,9 +5,9 @@
 
 |Argument | Default value | Description|
 | --- | --- | --- |
-| --namespace <br> -n | Null | Specify in which namespaces BFE Ingress Controller will monitor Ingress. Multiple namespaces are seperated by `,`. <br>Default value means to monitor all namespaces.  |
+| --namespace <br> -n | Empty String | Specify in which namespaces BFE Ingress Controller will monitor Ingress. Multiple namespaces are seperated by `,`. <br>Default value is empty string which means to monitor all namespaces. |
 | --ingress-class| bfe | Specify the `kubernetes.io/ingress.class` value of Ingress it monitors. <br>If not specified, BFE Ingress Controller monitors the Ingress with ingress class set as "bfe". Usually you don't need to specify it. |
-| --default-backend| Null | Specify name of default backend service, in the format of `namespace/name`.<br>If specified, requests that match no Ingress rule will be forwarded to the service specified. |
+| --default-backend| Empty String | Specify name of default backend service, in the format of `namespace/name`.<br>If specified, requests that match no Ingress rule will be forwarded to the service specified. |
 
 How to define：
 Define in config file of BFE Ingress Controller, like [controller.yaml](../../../examples/controller.yaml). Example：
diff --git a/docs/en_us/contribute/contribute-codes.md b/docs/en_us/contribute/contribute-codes.md
index cf316f85..72ff89d5 100644
--- a/docs/en_us/contribute/contribute-codes.md
+++ b/docs/en_us/contribute/contribute-codes.md
@@ -71,14 +71,15 @@ Below tutorial will guide you to submit code
     $ git commit -m "test=release/1.1"
     ```
     
-1. Keep local repository up-to-date
+8. Keep local repository up-to-date
 
-1. An experienced Git user pulls from the official repo often -- daily or even hourly, so they notice conflicts with others work early, and it's easier to resolve smaller conflicts.
+    An experienced Git user pulls from the official repo often -- daily or even hourly, so they notice conflicts with others work early, and it's easier to resolve smaller conflicts.
 
-   ```bash
-   git remote add upstream https://github.com/bfenetworks/bfe
-   git pull upstream develop
-   ```
+    ```bash
+    git remote add upstream https://github.com/bfenetworks/ingress-bfe
+    git fetch upstream
+    git pull upstream develop
+    ```
 
 10. Push to remote repository
 
diff --git a/docs/en_us/ingress/conflict.md b/docs/en_us/ingress/conflict.md
index 6db823ea..36ace790 100644
--- a/docs/en_us/ingress/conflict.md
+++ b/docs/en_us/ingress/conflict.md
@@ -1,15 +1,15 @@
 # Route Rule Conflict
 
 ## Definition
-If Ingress configuration is created with Ingress resources containing the same Ingress rule (host, path and advanced conditions are all the same), a route rule conflict happens. 
+If Ingress configurations will create Ingress resources containing at least one identical Ingress rule (host, path and advanced conditions are all the same), a route rule conflict happens. 
 
 ## Conflict handling: first-created-resource-win principle
 
 For those Ingress resources with route rule conflict, BFE Ingress Controller will follow first-created-resource-win principle and only takes the first created Ingress resource as valid.  
 
-This principle will be followed when route rule conflict happens within a namespace or among different namespaces.
+This principle will be followed when route rule conflict happens within a namespace or across different namespaces.
 
-For those Ingress resources invalid due to route rule conflict, error messages will be written to its annotation, see [Ingress Status](validate-state.md).
+For those invalid Ingress resources due to route rule conflict, error messages will be written to its annotation, see [Ingress Status](validate-state.md).
 
 ## Example
 
@@ -54,7 +54,7 @@ spec:
 In above configuration, there is conflict between ingress-A and ingress-B, and ingress-A is created before ingress-B. So only ingress-A will been created and take effect.
 
 ## Ingress status feedback
-If a Ingress resource is ignored (not take effect) due to route rule conflict, after the ingress status is written back, the `status` in `annotation` will be set as “fail”, and `message` will tell which Ingress resource it has conflict with.
+If an Ingress resource is invalid due to route rule conflict, after the ingress status is written back, the `status` in `annotation` will be set as “fail”, and `message` will tell which Ingress resource it has conflict with.
 
 In previous example, `annotation` for ingress status will be like:
 
diff --git a/docs/en_us/ingress/priority.md b/docs/en_us/ingress/priority.md
index 5bd46c0c..7527a6f7 100644
--- a/docs/en_us/ingress/priority.md
+++ b/docs/en_us/ingress/priority.md
@@ -1,11 +1,11 @@
 # Priority of route rules
 If a request matches multiple ingress rules, BFE Ingress Controller will decide which rule will be hit according to below strategies:
 
--  Compare the hostname and select the rule with more precise hostname;
--  If hostname is identical, select the rule with more precise path;
--  If both hostname and path are identical, select the rule with more matching advanced conditions;
--  If all the above rules fails, select the rule which matches an advanced condition of higher priority
-   - in advanced match condition, Cookie condition has higher priority than Header condition；
+-  Compare the hostname and select the rule with most precise hostname;
+-  If more than one rule is selected in the above step, select the rule with most precise path;
+-  If more than one rule is selected in the above step, select the rule with most advanced conditions;
+-  If more than one rule is selected in the above step, select the rule which matches an advanced condition of higher priority
+   - in advanced condition, Cookie condition has higher priority than Header condition；
 
 ## Examples
 ### Hostname precision first
@@ -44,7 +44,7 @@ spec:
               serviceName: service2
               servicePort: 80
 ```
-In above example, for requests generated by `curl "http://example.net/bar"`, rule with name `host_priority1` will be hit.
+In above example, for requests generated by `curl "http://example.net/bar"`, the rule in ingress `host_priority1` will be hit.
 
 ### Path precision first when hostname are identical
 ```yaml
@@ -83,9 +83,9 @@ spec:
               serviceName: service2
               servicePort: 80
 ```
-In above example, for requests generated by `curl "http://example.net/bar/foo" -H "Key: value"`, rule with name `path_priority1` will be hit
+In above example, for requests generated by `curl "http://example.net/bar/foo" -H "Key: value"`, the rule in ingress `path_priority1` will be hit
 
-### More matched advanced condition first, when hostname and path both identical
+### More advanced condition first, when hostname and path both identical
 ```yaml
 kind: Ingress
 apiVersion: networking.k8s.io/v1beta1
@@ -123,9 +123,9 @@ spec:
               serviceName: service2
               servicePort: 80
 ```
-In above example, for requests generated by `curl "http://example.net/bar/foo" -H "Key: value"`, rule with name `cond_priority1` will be hit
+In above example, for requests generated by `curl "http://example.net/bar/foo" -H "Key: value"`, the rule in ingress `cond_priority1` will be hit
 
-### Matched advanced condition with higher priority first, when above criteria are the same
+### Matched advanced condition with higher priority first, when multiple rules meet above criteria
 ```yaml
 kind: Ingress
 apiVersion: networking.k8s.io/v1beta1
@@ -163,5 +163,5 @@ spec:
               serviceName: service2
               servicePort: 80
 ```
-In above example, for requests generated by `curl "http://example.net/bar/foo" -H "Header-key: value" --cookie "cookie-key: value"`, rule with name `multi_cond_priority2` will be hit, for `Cookie` condition has higher priority than `Header` condition.
+In above example, for requests generated by `curl "http://example.net/bar/foo" -H "Header-key: value" --cookie "cookie-key: value"`, the rule in ingress `multi_cond_priority2` will be hit, because `Cookie` condition has higher priority than `Header` condition.
 
diff --git a/docs/en_us/ingress/tls.md b/docs/en_us/ingress/tls.md
index c820cbd8..13d32ce7 100644
--- a/docs/en_us/ingress/tls.md
+++ b/docs/en_us/ingress/tls.md
@@ -3,7 +3,7 @@ BFE Ingress Controller manages TLS certificates and secretes in the way defined
 
 TLS certificates and secretes are stored in `Secret`. See examples below:
 
-**Configurate Secret**
+**Configure Secret**
 
 ```yaml
 apiVersion: v1
@@ -16,7 +16,7 @@ data:
   tls.key: base64 encoded key
 type: kubernetes.io/tls
 ```
-**Configurate Ingress**
+**Configure Ingress**
 
 ```yaml
 apiVersion: networking.k8s.io/v1beta1
diff --git a/docs/zh_cn/FAQ/FAQ.md b/docs/zh_cn/FAQ/FAQ.md
index 64873313..1fbff95f 100644
--- a/docs/zh_cn/FAQ/FAQ.md
+++ b/docs/zh_cn/FAQ/FAQ.md
@@ -5,9 +5,9 @@
 
  选项 | 默认值 | 用途|
 | --- | --- | --- |
-| --namespace <br> -n | 空 | 设置需监听的ingress所在的namespace，多个namespace 之间用`,`分割。<br>默认监听所有的 namespace。  |
+| --namespace <br> -n | 空字符串 | 设置需监听的ingress所在的namespace，多个namespace 之间用`,`分割。<br>默认值为空字符串，表示监听所有的 namespace。  |
 | --ingress-class| bfe | 指定需监听的Ingress的`kubernetes.io/ingress.class`值。<br>如不指定，BFE Ingress Controller将监听class设置为bfe的Ingress。 通常无需设置。 |
-| --default-backend| 空 | 指定default-backend服务的名字，格式为`namespace/name`。<br>如指定default-backend，没有命中任何Ingress规则的请求，将被转发到default-backend。 |
+| --default-backend| 空字符串 | 指定default-backend服务的名字，格式为`namespace/name`。<br>如指定default-backend，没有命中任何Ingress规则的请求，将被转发到default-backend。 |
 
 设置方式：
 在BFE Ingress Controller的部署文件[controller.yaml](../../../examples/controller.yaml)中指定。例如：