Update Linkerd Governance (#5477)

The governance structure documented is `GOVERNANCE.md` is no longer
suitable for the project and doesn't reflect the reality of how changes
are made.

This change proposes an updated, simplified governance structure that
clearly outlines the expectations for maintainers around project
participation and decision making. It is expected that *most*
contributions will not come from maintainers; but we need a core group
of maintainers that are ultimately responsible for technical stewardship
of the project.

GOVERNANCE.md

@@ -2,46 +2,57 @@
 
 This document defines project governance for Linkerd.
 
-## Roles
+## Contributors
 
-There are two roles that convey decision-making powers: maintainer and
+Linkerd is for everyone. Anyone can become a Linkerd contributor simply by
-super-maintainer. MAINTAINERS.md defines the membership of these roles.
+contributing to the project, whether through code, documentation, blog posts,
+community management, or other means. As with all Linkerd community members,
+contributors are expected to follow the [Linkerd Code of
+Conduct][coc].
 
-## Expectations
+All contributions to Linkerd code, documentation, or other components in the
+Linkerd GitHub org must follow the guidelines in [CONTRIBUTING.md][contrib].
+Whether these contributions are merged into the project is the prerogative of
+the maintainers.
 
-Maintainers are responsible for one or more components, and are expected to
+## Maintainer Expectations
-contribute code, field incoming PRs, triage issues, proactively fix bugs, and
-generally perform maintenance tasks for these components.
 
-Super-maintainers are responsible for the project as a whole, and are expected
+Maintainers have the ability to merge code into the project. Anyone can
-to guide general project direction as well as being the final reviewer on PRs.
+become a Linkerd maintainer (see "Becoming a maintainer" below.)
 
-## Decisionmaking
+As such, there are certain expectations for maintainers. Linkerd maintainers
+are expected to:
 
-Ideally, all project decisions are resolved by consensus. If this is not
+* Review pull requests, triage issues, and fix bugs in their areas of
-possible, maintainers may call a vote. Unless otherwise specified in this
+  expertise, ensuring that all changes go through the project's code review
-document, the vote will be decided by a simple majority in which each
+  and integration processes.
-super-maintainer receives two votes and each maintainer receives one vote.
+* Monitor cncf-linkerd-* emails and the Linkerd Slack, and help out when
+  possible.
+* Rapidly respond to any time-sensitive security release processes.
+* Attend meetings with the Linkerd Steering Committee.
 
-## Changes in Maintainership
+If a maintainer is no longer interested in or cannot perform the duties
+listed above, they should move themselves to emeritus status. If necessary,
+this can also occur through the decision-making process outlined below.
 
-New maintainers must be proposed by an existing maintainer and must be elected
+### Maintainer decision-making
-by a 2/3 majority organization vote. Maintainers can be removed by a 2/3
-majority organization vote.
 
-Super-maintainers must be proposed by an existing super-maintainer and must be
+Ideally, all project decisions are resolved by maintainer consensus. If this
-elected by a 2/3 majority organization vote. Super-maintainers can be removed
+is not possible, maintainers may call a vote. The voting process is a simple
-by a 2/3 majority organization vote.
+majority in which each maintainer receives one vote.
 
-## GitHub Project Administration
+### Becoming a maintainer
 
-Maintainers will be added to the linkerd GitHub organization, and be made an
+Anyone can become a Linkerd maintainer. Maintainers should be extremely
-owner of the GitHub organization.
+proficient in Go and/or Rust; have relevant domain expertise; have the time
+and ability to meet the maintainer expectations above; and demonstrate the
+ability to work with the existing maintainers and project processes.
 
-## Approving PRs
+To become a maintainer, start by expressing interest to existing maintainers.
+Existing maintainers will then ask you to demonstrate the qualifications
+above by contributing PRs, doing code reviews, and other such tasks under
+their guidance. After several months of working together, maintainers will
+decide whether to grant maintainer status.
 
-All PRs must receive approval from at least one super maintainer before merge.
+[coc]: https://github.com/linkerd/linkerd/wiki/Linkerd-code-of-conduct
-
+[contrib]: https://github.com/linkerd/linkerd2/blob/main/CONTRIBUTING.md
-## Changes in Governance
-
-All changes in Governance require a 2/3 majority organization vote.

MAINTAINERS.md

@@ -1,6 +1,6 @@
 # Maintainers
 
-The Linkerd2 maintainers are:
+The Linkerd maintainers are:
 
 * Oliver Gould <ver@buoyant.io> @olix0r (super-maintainer)
 * Kevin Lingerfelt <kl@buoyant.io> @klingerf (super-maintainer)
@@ -13,6 +13,12 @@ The Linkerd2 maintainers are:
 * Risha Mars <mars@buoyant.io> @rmars
 * Zahari Dichev <zahari@buoyant.io> @zaharidichev
 
+## Emeritus
+
+Former maintainers include:
+
+* ...
+
 <!--
 # Adding a new maintainer