docs: fix typos (#20734)

Author: omahs

CONTRIBUTING.md

@@ -43,7 +43,7 @@ contributors, the general procedure for contributing has been established:
    1. Ensure that the proposal has been accepted.
    2. Ensure that nobody else has already begun working on this issue. If they have,
       make sure to contact them to collaborate.
-   3. If nobody has been assigned for the issue and you would like to work on it,
+   3. If nobody has been assigned to the issue and you would like to work on it,
       make a comment on the issue to inform the community of your intentions
       to begin work.
 5. To submit your work as a contribution to the repository follow standard GitHub best practices. See [pull request guideline](#pull-requests) below.
@@ -322,11 +322,11 @@ to developers who show an aptitude towards developing with this code base.
 
 Several different kinds of privileges may be granted however most common
 privileges to be granted are merge rights to either part of, or the entirety of the
-code base (through the GitHub `CODEOWNERS` file). The on-boarding process for
+code base (through the GitHub `CODEOWNERS` file). The onboarding process for
 new code owners is as follows: On a bi-monthly basis (or more frequently if
 agreeable) all the existing code owners will privately convene to discuss
 potential new candidates as well as the potential for existing code-owners to
-exit or "pass on the torch". This private meeting is to be a held as a
+exit or "pass on the torch". This private meeting is to be held as a
 phone/video meeting.
 
 Subsequently after the meeting, and pending final approval from the ICF,

README.md

@@ -78,7 +78,7 @@ Core Dependencies are the core libraries that an application may depend on.
 
 #### Module Dependencies
 
-Module Dependencies are the modules that a application may depend on and which version of the Cosmos SDK they are compatible with.
+Module Dependencies are the modules that an application may depend on and which version of the Cosmos SDK they are compatible with.
 
 > Note: The version table only goes back to 0.50.x, this is due to the reason that modules were not spun out into their own go.mods until 0.50.z. ❌ signals that the module was not spun out into its own go.mod file.
 

RELEASES.md

@@ -1,10 +1,10 @@
 # Releases
 
-The Cosmos-SDK follows both [0ver](https://0ver.org/) and [Semver](https://semver.org/). While this is confusing lets break it down: 0ver is used for the main Cosmos-SDK dependency (`github.com/cosmos/cosmos-sdk`) and Semver is used for all other dependencies.
+The Cosmos-SDK follows both [0ver](https://0ver.org/) and [Semver](https://semver.org/). While this is confusing let's break it down: 0ver is used for the main Cosmos-SDK dependency (`github.com/cosmos/cosmos-sdk`) and Semver is used for all other dependencies.
 
 ## Semver Dependencies
 
-Although we adhere to semantic versioning (semver), we have introduced a few modifications to accommodate the unique characteristics of blockchains. One significant divergence is that the major version (Y.x.x) is incremented solely when a consensus-breaking change occurs. On the other hand, the minor version (x.Y.x) is increased when there is a non-consensus-breaking alteration that also results in an incompatible API change. Patch versions will be bumped for all other changes that dont break the API nor Consensus. 
+Although we adhere to semantic versioning (semver), we have introduced a few modifications to accommodate the unique characteristics of blockchains. One significant divergence is that the major version (Y.x.x) is incremented solely when a consensus-breaking change occurs. On the other hand, the minor version (x.Y.x) is increased when there is a non-consensus-breaking alteration that also results in an incompatible API change. Patch versions will be bumped for all other changes that don't break the API nor Consensus. 
 
 ```mermaid
 flowchart TD

RELEASE_PROCESS.md

@@ -20,7 +20,7 @@ v1.0.0-beta1 → v1.0.0-beta2 → ... → v1.0.0-rc1 → v1.0.0-rc2 → ... →
     * perform functional tests
     * add more tests
     * release new beta version as the bugs are discovered and fixed.
-* After the team feels that the `main` works fine we create a `release/vY` branch (going forward known a release branch), where `Y` is the version number, with the patch part substituted to `x` (eg: 0.42.x, 1.0.x). Ensure the release branch is protected so that pushes against the release branch are permitted only by the release manager or release coordinator.
+* After the team feels that the `main` works fine we create a `release/vY` branch (going forward known as release branch), where `Y` is the version number, with the patch part substituted to `x` (eg: 0.42.x, 1.0.x). Ensure the release branch is protected so that pushes against the release branch are permitted only by the release manager or release coordinator.
     * **PRs targeting this branch can be merged _only_ when exceptional circumstances arise**
     * update the GitHub mergify integration by adding instructions for automatically backporting commits from `main` to the `release/vY` using the `backport/Y` label.
 * In the release branch prepare a new version section in the `CHANGELOG.md`
@@ -31,7 +31,7 @@ v1.0.0-beta1 → v1.0.0-beta2 → ... → v1.0.0-rc1 → v1.0.0-rc2 → ... →
 * Remove GitHub workflows that should not be in the release branch
     * `test.yml`: All standalone go module tests should be removed (expect `./simapp`, and `./tests`, SDK and modules tests).
         * These packages are tracked and tested directly on main.
-    * `build.yml`: Only the SDK and SimApp needs to be built on release branches.
+    * `build.yml`: Only the SDK and SimApp need to be built on release branches.
         * Tooling is tracked and tested directly on main.
         * This does not apply for tooling depending on the SDK (e.g. `confix`)
     * Update `Dockerfile` to not use latest go.mod and go.sum files.
@@ -66,7 +66,7 @@ After the release branch has all commits required for the next patch release:
 
 * Update `CHANGELOG.md` and `RELEASE_NOTES.md` (if applicable).
 * Create a new annotated git tag (eg `git -a v1.1.0`) in the release branch.
-    * If the release is a submodule update, first go the submodule folder and name the tag prepending the path to the version:
+    * If the release is a submodule update, first go to the submodule folder and name the tag prepending the path to the version:
       `cd core && git -a core/v1.1.0` or `cd tools/cosmovisor && git -a tools/cosmovisor/v1.4.0`
 * Create a GitHub release (if applicable).
 
@@ -138,7 +138,7 @@ See the SDK's policy on migrations [here](https://docs.cosmos.network/main/migra
 
 * State machine changes.
 * Breaking changes in Protobuf definitions, as specified in [ADR-044](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-044-protobuf-updates-guidelines.md).
-* Changes that introduces API breakages (e.g. public functions and interfaces removal/renaming).
+* Changes that introduce API breakages (e.g. public functions and interfaces removal/renaming).
 * Client-breaking changes in gRPC and HTTP request and response types.
 * CLI-breaking changes.
 * Cosmetic fixes, such as formatting or linter warning fixes.
@@ -182,15 +182,15 @@ As rule of thumb, the following changes will **NOT** be automatically accepted i
 ```md
 #### Impact
 
-Brief xplanation of the effects of the bug on users and a justification for backporting the fix to the stable release.
+Brief explanation of the effects of the bug on users and a justification for backporting the fix to the stable release.
 
 #### Test Case
 
 Detailed instructions on how to reproduce the bug on Stargate's most recently published point-release.
 
 #### Regression Potential
 
-Explanation on how regressions might manifest - even if it's unlikely.
+Explanation of how regressions might manifest - even if it's unlikely.
 It is assumed that stable release fixes are well-tested and they come with a low risk of regressions.
 It's crucial to make the effort of thinking about what could happen in case a regression emerges.
 ```

ROADMAP.md

@@ -45,7 +45,7 @@ Welcome to the Cosmos SDK's team roadmap.
         *  Migrating 3 modules to use collections would help in show users how to migrate users
 * [ ] [Release ORM v1](https://github.com/cosmos/cosmos-sdk/issues/11088)
 * [x] [Sign mode textual](https://github.com/cosmos/cosmos-sdk/issues/11970) 
-    * Sign mode textual has been under construction for 2 quarters now, this quarter the goal is to move towards v1 and potentially line up a audit before final release.
+    * Sign mode textual has been under construction for 2 quarters now, this quarter the goal is to move towards v1 and potentially line up an audit before final release.
 * [x] Core API
     * [Merge ADR for Core API](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-063-core-module-api.md) 
     * Migrate three modules to use core api
@@ -66,7 +66,7 @@ Welcome to the Cosmos SDK's team roadmap.
 ### Testing
 
 * [x] [integration testing framework](https://github.com/cosmos/cosmos-sdk/issues/14145) 
-    * design and merge a integration testing framework. 
+    * design and merge an integration testing framework. 
     * The goals of the framework would that a module only needs to depend on modules that it depends on outside of testing, not all modules in the sdk like today.
 
 
@@ -200,7 +200,7 @@ Issue: https://github.com/cosmos/iavl/issues/548
 
 * [ ] [Invariant Checking](https://github.com/cosmos/cosmos-sdk/issues/15706)
     * Objective:
-        * Design a new system for checking invairants
+        * Design a new system for checking invariants
         * Implement changes
         * Audit current invariants
     * Progress: 

UPGRADING.md

@@ -476,7 +476,7 @@ Use `confix` to clean-up your `app.toml`. A nginx (or alike) reverse-proxy can b
 
 #### Database Support
 
-ClevelDB, BoltDB and BadgerDB are not supported anymore. To migrate from a unsupported database to a supported database please use a database migration tool.
+ClevelDB, BoltDB and BadgerDB are not supported anymore. To migrate from an unsupported database to a supported database please use a database migration tool.
 
 ### Protobuf
 
@@ -1219,7 +1219,7 @@ mistakes.
 
 #### `x/params`
 
-* The `x/params` module has been deprecated in favour of each module housing and providing way to modify their parameters. Each module that has parameters that are changeable during runtime have an authority, the authority can be a module or user account. The Cosmos SDK team recommends migrating modules away from using the param module. An example of how this could look like can be found [here](https://github.com/cosmos/cosmos-sdk/pull/12363).
+* The `x/params` module has been deprecated in favour of each module housing and providing way to modify their parameters. Each module that has parameters that are changeable during runtime has an authority, the authority can be a module or user account. The Cosmos SDK team recommends migrating modules away from using the param module. An example of how this could look like can be found [here](https://github.com/cosmos/cosmos-sdk/pull/12363).
 * The Param module will be maintained until April 18, 2023. At this point the module will reach end of life and be removed from the Cosmos SDK.
 
 #### `x/gov`
@@ -1232,11 +1232,11 @@ More information can be found in the gov module [client documentation](https://d
 
 #### `x/staking`
 
-The `staking module` added a new message type to cancel unbonding delegations. Users that have unbonded by accident or wish to cancel a undelegation can now specify the amount and valdiator they would like to cancel the unbond from
+The `staking module` added a new message type to cancel unbonding delegations. Users that have unbonded by accident or wish to cancel an undelegation can now specify the amount and validator they would like to cancel the unbond from
 
 ### Protobuf
 
-The `third_party/proto` folder that existed in [previous version](https://github.com/cosmos/cosmos-sdk/tree/v0.45.3/third_party/proto) now does not contains directly the [proto files](https://github.com/cosmos/cosmos-sdk/tree/release/v0.46.x/third_party/proto).
+The `third_party/proto` folder that existed in [previous version](https://github.com/cosmos/cosmos-sdk/tree/v0.45.3/third_party/proto) now does not contain directly the [proto files](https://github.com/cosmos/cosmos-sdk/tree/release/v0.46.x/third_party/proto).
 
 Instead, the SDK uses [`buf`](https://buf.build). Clients should have their own [`buf.yaml`](https://docs.buf.build/configuration/v1/buf-yaml) with `buf.build/cosmos/cosmos-sdk` as dependency, in order to avoid having to copy paste these files.