Update CONTRIBUTING.md Point Release Procedure (#7999)

* Update CONTRIBUTING.md

* Update CONTRIBUTING.md

Co-authored-by: billy rennekamp <billy.rennekamp@gmail.com>

* Update CONTRIBUTING.md

Co-authored-by: billy rennekamp <billy.rennekamp@gmail.com>

* Update CONTRIBUTING.md

Co-authored-by: billy rennekamp <billy.rennekamp@gmail.com>

* Update CONTRIBUTING.md

Co-authored-by: billy rennekamp <billy.rennekamp@gmail.com>

* Update CONTRIBUTING.md

Co-authored-by: billy rennekamp <billy.rennekamp@gmail.com>

* updates to concept & release approval process

* update codeowners addition process

* time bound updates

* Update CONTRIBUTING.md

Co-authored-by: Alessio Treglia <alessio@tendermint.com>

Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com>
Co-authored-by: billy rennekamp <billy.rennekamp@gmail.com>
Co-authored-by: Alessio Treglia <alessio@tendermint.com>
Co-authored-by: Cory Levinson <cjlevinson@gmail.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

CONTRIBUTING.md

@@ -218,7 +218,7 @@ only pull requests targeted directly against master.
 ### Development Procedure
 
 - the latest state of development is on `master`
-- `master` must never fail `make test` or `make test_cli`
+- `master` must never fail `make lint test test-race`
 - `master` should not fail `make lint`
 - no `--force` onto `master` (except when reverting a broken commit, which should seldom happen)
 - create a development branch either on github.com/cosmos/cosmos-sdk, or your fork (using `git remote add origin`)
@@ -227,7 +227,7 @@ only pull requests targeted directly against master.
 ### Pull Merge Procedure
 
 - ensure pull branch is rebased on `master`
-- run `make test` and `make test_cli` to ensure that all tests pass
+- run `make test` to ensure that all tests pass
 - merge pull request
 
 ### Release Procedure
@@ -306,9 +306,11 @@ 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
-phone/video meeting. Subsequently at the end of the meeting, one of the existing
+phone/video meeting.
-code owners should open a PR modifying the `CODEOWNERS` file. The other code
+
-owners should then all approve this PR to publicly display their support.
+Subsequently after the meeting, and pending final approval from the ICF,
+one of the existing code owners should open a PR modifying the `CODEOWNERS` file.
+The other code owners should then all approve this PR to publicly display their support.
 
 Only if unanimous consensus is reached among all the existing code-owners will
 an invitation be extended to a new potential-member. Likewise, when an existing
@@ -318,6 +320,95 @@ should be taken. If however, a code-owner is demonstrably shown to intentionally
 have had acted maliciously or grossly negligent, code-owner privileges may be
 stripped with no prior warning or consent from the member in question.
 
+Other potential removal criteria:
+  * Missing 3 scheduled meetings results in ICF evaluating whether the member should be
+    removed / replaced
+  * Violation of Code of Conduct
+
 Earning this privilege should be considered to be no small feat and is by no
 means guaranteed by any quantifiable metric. It is a symbol of great trust of
 the community of this project.
+
+
+## Concept & Release Approval Process
+
+The process for how Cosmos SDK maintainers take features and ADRs from concept to release
+is broken up into three distinct stages: **Strategy Discovery**, **Concept Approval**, and 
+**Implementation & Release Approval**
+
+
+### Strategy Discovery
+
+* Develop long term priorities, strategy and roadmap for the SDK
+* Release committee not yet defined as there is already a roadmap that can be used for the time being
+
+### Concept Approval
+
+* Architecture Decision Records (ADRs) may be proposed by any contributors or maintainers of the Cosmos SDK,
+    and should follow the guidelines outlined in the
+    [ADR Creation Process](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/PROCESS.md)
+* After proposal, a time bound period for Request for Comment (RFC) on ADRs commences
+* ADRs are intended to be iterative, and may be merged into `master` while still in a `Proposed` status
+
+**Time Bound Period**
+
+* Once a PR for an ADR is opened, reviewers are expected to perform a first
+  review within 1 week of pull request being open
+* Time bound period for individual ADR Pull Requests to be merged should not exceed 2 weeks
+* Total time bound period for an ADR to reach a decision (`ABANDONED | ACCEPTED | REJECTED`) should not exceed 4 weeks
+
+If an individual Pull Request for an ADR needs more time than 2 weeks to reach resolution, it should be merged
+in current state (`Draft` or `Proposed`), with its contents updated to summarize
+the current state of its discussion.
+
+If an ADR is taking longer than 4 weeks to reach a final conclusion, the **Concept Approval Committee** 
+should convene to rectify the situation by either:
+- unanimously setting a new time bound period for this ADR
+- making changes to the Concept Approval Process (as outlined here)
+- making changes to the members of the Concept Approval Committee
+
+**Approval Committee & Decision Making**
+
+In absense of general consensus, decision making requires ⅔ vote from the three members
+of the **Concept Approval Committee**.
+
+**Committee Members**
+
+* Core Members: **Aaron** (Regen), **Bez** (Fission), **Alessio** (AiB)
+* Secondary pool of candidates to replace / substitute:
+    * **Chris Goes** (IG), **Sunny** (Sikka)
+
+**Committee Criteria**
+
+Members must:
+
+* Participate in all or almost all ADR discussions, both on Github as well as in bi-weekly Architecture Review
+  meetings
+* Be active contributors to the SDK, and furthermore should be continuously making substantial contributions
+  to the project's codebase, review process, documentation and ADRs
+* Have stake in the Cosmos SDK project, represented by:
+  * Being a client / user of the Comsos SDK
+  * "[giving back](https://www.debian.org/social_contract)" to the software
+* Delegate representation in case of vacation or absence
+
+Code owners need to maintain participation in the process, ideally as members of **Concept Approval Committee**
+members, but at the very least as active participants in ADR discussions
+
+Removal criteria:
+
+* Missing 3 meetings results in ICF evaluating whether the member should be removed / replaced
+* Violation of Code of Conduct
+
+### Implementation & Release Approval
+
+The following process should be adhered to both for implementation PRs corresponding to ADRs, as
+well as for PRs made as part of a release process:
+
+* Code reviewers should ensure the PR does exactly what the ADR said it should
+* Code reviewers should have more senior engineering capability
+* ⅔ approval is required from the **primary repo maintainers** in `CODEOWNERS`
+  * Secondary pool of candidates to replace / substitute are listed as **secondary repo maintainers** in `CODEOWNERS`
+ 
+*Note: For any major or minor release series denoted as a "Stable Release" (e.g. v0.39 "Launchpad"), a separate release
+committee is often established. Stable Releases, and their corresponding release committees are documented
+separately in [STABLE_RELEASES.md](./STABLE_RELEASES.md)*