docs: fix typos

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,5 +1,5 @@
-Please go the the `Preview` tab and select the appropriate sub-template:
+Please go to the `Preview` tab and select the appropriate sub-template:
 
 * [Production code](?expand=1&template=production.md) - for types `fix`, `feat`, and `refactor`.
 * [Docs](?expand=1&template=docs.md) - for documentation changes.
-* [Others](?expand=1&template=others.md) - for changes that do not affect production code.
+* [Others](?expand=1&template=others.md) - for changes that do not affect production code.

CONTRIBUTING.md

@@ -242,7 +242,7 @@ unclog add \
    -s "${section}" \
    -m "${description}" \
 
-# add a entry to a component 
+# add an entry to a component 
 unclog add 
    -i "${pr-number}-${short-description}" \
    -p "${pr-number}" \
@@ -264,7 +264,7 @@ unclog add -i "1024-jail-throttling-v2" -p 1024 -c consumer -s features -m "Add
 ```
 
 **Note:** `unclog add` requires an editor. This can be set either by configuring 
-an `$EDITOR` environment variable or by manually specify an editor binary path 
+an `$EDITOR` environment variable or by manually specifying an editor binary path 
 via the `--editor` flag. 
 
 **Note:** Changelog entries should answer the question: "what is important about this

docs/docs/consumer-development/changeover-procedure.md

@@ -46,7 +46,7 @@ RevisionNumber: 0, RevisionHeight: 111
 
 * `binary_hash` may not be available ahead of time. All chains performing the changeover go through rigorous testing - if bugs are caught and fixed the hash listed in the proposal may not be the most recent one.
 
-* `spawn_time` listed in the proposal MUST be before the `upgrade_height` listed in the the upgrade proposal on the standalone chain.
+* `spawn_time` listed in the proposal MUST be before the `upgrade_height` listed in the upgrade proposal on the standalone chain.
 :::caution
 `spawn_time` must occur before the `upgrade_height` on the standalone chain is reached because the `provider` chain must generate the `ConsumerGenesis` that contains the **validator set** that will be used after the changeover.
 :::
@@ -139,7 +139,7 @@ Example of such a repository can be found [here](https://github.com/hyphacoop/ic
 
 ## 3. Submit a ConsumerChainAddition Governance Proposal to the provider
 
-Before you submit a `ConsumerChainAddition` proposal, please provide a `spawn_time` that is **before** the the `upgrade_height` of the upgrade that will introduce the `ccv module` to your chain.
+Before you submit a `ConsumerChainAddition` proposal, please provide a `spawn_time` that is **before** the `upgrade_height` of the upgrade that will introduce the `ccv module` to your chain.
 :::danger
 If the `spawn_time` happens after your `upgrade_height` the provider will not be able to communicate the new validator set to be used after the changeover.
 :::
@@ -211,7 +211,7 @@ Example of a consumer chain addition proposal.
 	// channel is created on top of the same connection as the CCV channel.
 	// Note that transfer_channel_id is the ID of the channel end on the consumer chain.
     // it is most relevant for chains performing a standalone to consumer changeover
-    // in order to maintan the existing ibc transfer channel
+    // in order to maintain the existing ibc transfer channel
     "distribution_transmission_channel": "channel-123"  // NOTE: use existing transfer channel if available
 }
 ```

docs/docs/validators/changeover-procedure.md

@@ -67,7 +67,7 @@ If you are validating both the `standalone` and the `provider`, you **can** use
 
 Yes.
 
-Please assign your consensus key as stated aboce.
+Please assign your consensus key as stated above.
 
 ### Can I set up a new node to validate the `standalone/consumer` chain after it transitions to replicated security?
 
@@ -76,7 +76,7 @@ Yes.
 If you are planning to do this please make sure that the node is synced with `standalone` network and to submit `AssignConsumerKey` tx before `spawn_time`.
 
 
-###  What happens to the `standalone` validator set after it after it transitions to replicated security?
+###  What happens to the `standalone` validator set after it transitions to replicated security?
 
 The `standalone` chain validators will stop being validators after the first 3 blocks are created while using replicated security. The `standalone` validators will become **governors** and still can receive delegations if the `consumer` chain is using the `consumer-democracy` module.
 

docs/docs/validators/overview.md

@@ -96,7 +96,7 @@ To learn more about equivocation handling in replicated security check out the [
 ## Key assignment
 Validators can use different consensus keys on the provider and each of the consumer chains. The consumer chain consensus key must be registered on the provider before use.
 
-For more information check our the [Key assignment overview and guide](../features/key-assignment.md)
+For more information check out the [Key assignment overview and guide](../features/key-assignment.md)
 
 ## References:
 - [Cosmos Hub Validators FAQ](https://hub.cosmos.network/main/validators/validator-faq.html)