fix typo

README.md

@@ -15,7 +15,7 @@ Chaos Mesh is a cloud-native Chaos Engineering platform that orchestrates chaos
 
 - **Chaos Operator**: the core component for chaos orchestration. Fully open sourced.
 - **Chaos Dashboard**: a visualized panel that shows the impacts of chaos experiments on the online services of the system; under development; 
-curently only supports chaos experiments on TiDB(https://github.com/pingcap/tidb).
+currently only supports chaos experiments on TiDB(https://github.com/pingcap/tidb).
 
 See the following demo video for a quick view of Chaos Mesh:
 
@@ -28,7 +28,7 @@ custom definitions for chaos experiments and automatic orchestration. There are
 
 **Controller-manager**: used to schedule and manage the lifecycle of CRD objects
 
-**Chaos-daemon**: runs as daemonset with privileged system permissions over network, Cgroup, etc. for a specifc node
+**Chaos-daemon**: runs as daemonset with privileged system permissions over network, Cgroup, etc. for a specific node
 
 **Sidecar**: a special type of container that is dynamically injected into the target Pod by the webhook-server, which can be used for hijacking I/O of the application container.
 
@@ -45,7 +45,7 @@ which correspond to the following major actions (experiments):
 - network-partition: Simulate network partition.
 - IO chaos: Simulate file system faults such as I/O delay, read/write errors, etc.
 - time chaos: The selected pod will be injected clock skew.
-- kernel chaos: The selected pod will be injected with (slab,bio,etc) errors.
+- kernel chaos: The selected pod will be injected with (slab, bio, etc) errors.
 
 ## Quick start
 
@@ -75,7 +75,7 @@ Please reach out for bugs, feature requests, and other issues via:
 
 - Following us on Twitter at [@chaos_mesh](https://twitter.com/chaos_mesh).
 - The #sig-chaos-mesh channel in the [TiDB Community](https://pingcap.com/tidbslack) slack workspace.
-- Filing a issue or opening a PR against this repo.
+- Filing an issue or opening a PR against this repo.
 
 ### Community meeting
 

ROADMAP.md

@@ -3,7 +3,7 @@
 This document defines the roadmap for Chaos Mesh development.
 
 ## v1.0
-- [x] Support time skew chaos. Simulate time jumping forward or backword.
+- [x] Support time skew chaos. Simulate time jumping forward or backward.
 - [x] Add container kill chaos. Simulate killing a specified container in a multi-container pod.
 - [x] Add CPU chaos. Simulate CPU being busy.
 - [x] Add memory chaos. Simulate memory allocation failure.

doc/run_chaos_mesh.md

@@ -9,8 +9,8 @@ The first step is always to have the target cluster to test deployed. For illust
 
 You can follow the instructions in the following two documents to deploy a TiDB cluster:
 
-* [Deploy using kind](https://pingcap.com/docs/stable/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-kind/)
-* [Deploy using minikube](https://pingcap.com/docs/stable/tidb-in-kubernetes/get-started/deploy-tidb-from-kubernetes-minikube/)
+* [Deploy using kind](https://pingcap.com/docs/tidb-in-kubernetes/stable/deploy-tidb-from-kubernetes-kind/)
+* [Deploy using minikube](https://pingcap.com/docs/tidb-in-kubernetes/stable/deploy-tidb-from-kubernetes-minikube/)
 
 ## Step 2: Define the experiment config file
 

doc/stress_chaos.md

@@ -2,13 +2,13 @@
 
 This document helps you to build stress chaos experiments.
 
-Stress chaos is a chaos to generate plenty of stresses over a collection of pods. The stressors is injected into the target pods via the `chaos-daemon` internally. 
+Stress chaos is a chaos to generate plenty of stresses over a collection of pods. The stressors are injected into the target pods via the `chaos-daemon` internally. 
 
 A `StressChaos` shares common configurations like other chaos, such as how to select pods, how to specify periodic chaos ... (You can refer to other docs for how to use them). It defines stressors in **either** of the following two ways:
 
 * `stressors`
 
-  Stressors defines plenty of stressors supported to stress system components out. You can use one or more of them to make up various kinds of stresses. At least one of the stressors should be specified. The following is supported stressors for now:
+  Stressors define plenty of stressors supported to stress system components out. You can use one or more of them to make up various kinds of stresses. At least one of the stressors should be specified. The following is supported stressors for now:
 
   1. `memory`
 
@@ -30,7 +30,7 @@ A `StressChaos` shares common configurations like other chaos, such as how to se
 
 * `stressngStressors`
 
-  StressngStressors defines plenty of stressors just like `Stressors` except that it's an experimental feature and more powerful. You can define stressors in `stress-ng` (see also `man stress-ng`) dialect, however not all of the supported stressors are well tested (**You have been warned**). It may be retired in later releases. You should always use `Stressors` to define the stressors and use this only when you want more stressors unsupported by `Stressors`. When both `StressngStressors` and `Stressors` are defined, `StressngStressors` wins. 
+  StressngStressors define plenty of stressors just like `Stressors` except that it's an experimental feature and more powerful. You can define stressors in `stress-ng` (see also `man stress-ng`) dialect, however not all of the supported stressors are well tested (**You have been warned**). It may be retired in later releases. You should always use `Stressors` to define the stressors and use this only when you want more stressors unsupported by `Stressors`. When both `StressngStressors` and `Stressors` are defined, `StressngStressors` wins. 
 
 Let's try it out! An example `yaml` of `StressChaos` which burns 1 CPU for 30 seconds in every 2 minutes is listed below: