Merge pull request #57 from Veeupup/fix_doc_typo

fix some guide doc typo

change-log.md

@@ -553,6 +553,8 @@
 
 ### Fixed:
 
+-   Fixed: [178d520](https://github.com/veeupup/openraft/commit/178d520e3db47b361582fe4aedd96f04a5dae160) typo; by Veeupup; 2022-01-04
+
 -   Fixed: [fc8e92a8](https://github.com/datafuselabs/openraft/commit/fc8e92a8207c1cf8bd1dba2e8de5c0c5eebedc1c) typo; by drdr xp; 2021-07-12
 
 -   Fixed: [447dc11c](https://github.com/datafuselabs/openraft/commit/447dc11cab51fb3b1925177d13e4dd89f998837b) when finalize_snapshot_installation, memstore should not load membership from its old log that are going to be overridden by snapshot.; by drdr xp; 2021-07-13

guide/src/cluster-controls.md

@@ -1,6 +1,6 @@
 # Cluster Controls
 
-A raft cluster may be control in various ways using the API methods of the `Raft` type.
+A raft cluster may be controlled in various ways using the API methods of the `Raft` type.
 This allows the application to influence the raft behavior.
 
 There are several concepts related to cluster control:

guide/src/delete_log.md

@@ -1,4 +1,4 @@
-When appending logs or install snapshot(another form of appending logs),
+When appending logs or installing snapshot(another form of appending logs),
 Conflicting logs **should** be removed.
 
 To maintain log consistency, it does not need to delete.
@@ -11,17 +11,17 @@ if the logs from the new leader are committed.
 But membership changing requires it to remove the incompatible logs when appending.
 This is what raft did wrongly.
 
-If membership log are ketp in a separate log column, there wont be such problem.
-But membership a mixed into business log.
+If membership logs are kept in a separate log column, there wont be such a problem.
+But membership a mixed into the business log.
 which makes it a non-WAL storage.
 
 The following is an exmaple of why logs must be removed:
-A membership change log will only appended if the previous membership log is committed,
+A membership change log will only be appended if the previous membership log is committed,
 which is the algo raft defined.
-A non committed membership log is only allowed to present if any quorum in it intersection with a quorum in the committed config.
+A non-committed membership log is only allowed to present if any quorum is in its intersection with a quorum in the committed config.
 
-But when new logs are appended, there could be some membership log that is not compatible with a membership log in the incompatible logs.
-which results in a brain break.
+But when new logs are appended, there could be a membership log that is not compatible with a membership log in the incompatible logs.
+which results in a split-brain.
 
 E.g.:
 
@@ -39,7 +39,7 @@ m'2 = {R3,X,Y} // final
 m3 = {R1,U,V} x {R1,R2,R3} 
 
 m3 is compatible with the committed membership log when it is created.
-But not compatible with other's
+But not compatible with others'
 
 ```
 R1 L1 e1,e2,m3            m'1,m'2,m3

guide/src/dynamic-membership.md

@@ -37,15 +37,15 @@ and immediately begin syncing logs from the leader.
 
 This method will initiate a membership change.
 
-If there are nodes in the given config is not a learner, this method will add it
+If there are nodes in the given config that is not a learner, this method will add it
 as Learner first.
 Thus it is recommended that application always call `Raft::add_learner` first.
 Otherwise `change_membership` may block for long before committing the
 given membership and return.
 
 The new membership config specified by this method will take effect at once.
 
-Once the new config is committed, a Voter that is no in the new config will
+Once the new config is committed, a Voter that is not in the new config will
 revert to a Learner and is ready to remove.
 
 Correctness constrains:

guide/src/threading.md

@@ -2,7 +2,7 @@
 
 There are several threads, AKA tokio-tasks in this raft impl:
 
-- RaftCore: all log and state machine operation is done in this thread.
+- RaftCore: all logs and state machine operations are done in this thread.
   Thus there is no race condition
 
   - All raft state runs in this task, such as LeaderState, CandidateState etc.
@@ -82,13 +82,13 @@ User
 
 - Replication to RaftCore:
 
-    - Replication task send the already replicated log id
+    - Replication task sends the already replicated log id
         to RaftCore through another per-replication channel.
 
-    - Replication task send a `NeedSnapshot` request through the same channel to
+    - Replication task sends a `NeedSnapshot` request through the same channel to
         ask RaftCore to build a snapshot if there is no log a follower/learner
         needs.
 
 - Build-snapshot to RaftCore: RaftCore spawn a separate task to build a snapshot
-    asynchronously. When finished, the spawned task send to RaftCore a message
+    asynchronously. When finished, the spawned task sends to RaftCore a message
     including the snapshot info.