[Vote] Governance update around maintainership (#4875)

* New governance rules around maintainership

Signed-off-by: Alvin Lin <alvinlin@amazon.com>

* Update the 2/3 vote of removing ineactive maintainer

Signed-off-by: Alvin Lin <alvinlin@amazon.com>

* Use URL for README.md and RELEASE.md to fix build break

Signed-off-by: Alvin Lin <alvinlin@amazon.com>

* Remove trailing space

Signed-off-by: Alvin Lin <alvinlin@amazon.com>

* Update GOVERNANCE.md

Co-authored-by: Friedrich Gonzalez <friedrichg@gmail.com>
Signed-off-by: Alvin Lin <alvinlin123@gmail.com>

Signed-off-by: Alvin Lin <alvinlin@amazon.com>
Signed-off-by: Alvin Lin <alvinlin123@gmail.com>
Co-authored-by: Friedrich Gonzalez <friedrichg@gmail.com>

Author: alvinlin123

GOVERNANCE.md

@@ -7,13 +7,30 @@ This document defines project governance for the project.
 The Cortex project employs voting to ensure no single member can dominate the project. Any maintainer may cast a vote. To avoid having a single company dominate the project, at most two votes from maintainers working for the same company will count.
 
 For formal votes, a specific statement of what is being voted on should be added to the relevant github issue or PR, and a link to that issue or PR added to the maintainers meeting agenda document.
-Maintainers should indicate their yes/no vote on that issue or PR, and after a suitable period of time, the votes will be tallied and the outcome noted.
+
+Maintainers should indicate their yes/no vote on that issue or PR, and after a suitable period of time (minimum 2 business weeks), the votes will be tallied and the outcome noted. Maintainers who do not cast a vote, after a suitable period of time, are not included in the majority calculation.
+
+
+## Maintainer duties
+
+Maintainers are required to participate in the project, by joining discussions, submitting and reviewing pull requests, answering user questions, among others.
+
+Besides that, we have one concrete activity in which maintainers have to engage from time to time: releasing new versions of Cortex. This process ideally takes only a couple of hours, but requires coordination on different fronts. Even though the process is well documented, it is not without eventual glitches, so, each release needs a "Release shepherd". How it works is described in the [RELEASE.md](https://github.com/cortexproject/cortex/blob/master/RELEASE.md) file.
 
 ## Changes in Maintainership
 
-New maintainers are proposed by an existing maintainer and are elected by a 2/3 majority vote.
+Contributors who are interested in becoming a maintainer, if performing relevant responsibilities, should discuss their interest with the existing maintainers. New maintainers must be nominated by an existing maintainer and must be elected by 2/3 majority vote.
+
+We do not expect anyone to make a permanent commitment to be a Cortex maintainer forever. After all, circumstances change,
+people get new jobs, new interests, and may not be able to continue contributing to the project. At the same time, we need
+to keep the list of maintainers current in order to have effective governance. People may be removed from the current list
+of maintainers via one of the following ways:
+  * They can resign
+  * If they stop contributing to the project for a period of 6 months or more
+  * By a 2/3 majority vote from active maintainers
 
-Maintainers can be removed by a 2/3 majority vote.
+Former maintainers are recognized with an honorary _Emeritus Maintainer_ status, and have their names permanently
+listed in the [README](https://github.com/cortexproject/cortex/blob/master/README.md) as a form of gratitude for their contributions.
 
 ## Approving PRs