Correct minor typos in readmes

packages/dds/matrix/README.md

@@ -141,13 +141,13 @@ axis is typically within an order of magnitude compared to sequentially accessin
 
 Shared Matrix allows a one-way switch from LWW to FWW. This is introduced in order to handle conflict
 when multiple clients at once initialize a cell. Using FWW, will help clients to receive a `conflict` event in case
-their change was rejected. They can resolve conflict with the new information that they received in the event.
+their change was rejected. They can resolve conflicts with the new information that they received in the event.
 This event is only emitted when the SetCell Resolution Policy is First Write Win(FWW). This is emitted when two clients
 race and send changes without observing each other changes, the changes that gets sequenced last would be rejected, and
 only client whose changes were rejected would be notified via this event, with expectation that it will merge its changes
 back by accounting new information (state from winner of the race).
 
-Some cases which documents how the Set op changes are applied or rejected during LWW -> FWW switch as some clients will
+Some cases which document how the Set op changes are applied or rejected during LWW -> FWW switch as some clients will
 be in FWW mode and some will in LWW mode. When app calls `switchSetCellPolicy` the policy is changed to FWW mode
 immediately and then later communicated to other clients via next SetOp which is made on the matrix.
 

packages/dds/register-collection/README.md

@@ -42,9 +42,9 @@ API documentation for **@fluidframework/register-collection** is available at <h
 
 ### Detecting concurrency in Fluid
 
-In distributed systems literaure, detecting concurrency requires some form of logical/phsical clock. A popular technique used in replicated databases such as dynamodb is called version vectors where each key stores a collection of `[time, value]` tuples. `time` is essentially a reference clock used to decide concurrency amongst updates. Each update to a key includes the `time`, essentially to indicate how `caught up` the replica was during that update.
+In distributed systems literature, detecting concurrency requires some form of logical/physical clock. A popular technique used in replicated databases such as dynamodb is called version vectors where each key stores a collection of `[time, value]` tuples. `time` is essentially a reference clock used to decide concurrency amongst updates. Each update to a key includes the `time`, essentially to indicate how `caught up` the replica was during that update.
 
-In Fluid, each operation contains a referenceSequenceNumber (`refSeq`), which essenially refers to how caught up the client was (in terms of sequence number) during that update. We can use this property to implement a similar concurreny model. Mathematically, if an update has a `refSeq N`, it can overwrite/discard any other prior values with `sequenceNumber (seq) <= N`. It is safe to do so because the client must have seen all those updates before posting it's own update. Hence this update is not concurrent with those overwritten updates. However, the update is still concurrent with any other update with `seq > N`. Therefore those versions are still kept.
+In Fluid, each operation contains a referenceSequenceNumber (`refSeq`), which essentially refers to how caught up the client was (in terms of sequence number) during that update. We can use this property to implement a similar concurrency model. Mathematically, if an update has a `refSeq N`, it can overwrite/discard any other prior values with `sequenceNumber (seq) <= N`. It is safe to do so because the client must have seen all those updates before posting its own update. Hence this update is not concurrent with those overwritten updates. However, the update is still concurrent with any other update with `seq > N`. Therefore those versions are still kept.
 
 ### Conflict resolution policies