Update to feature-maintainer and wording on approval/removal. +Emeritus maintainers

artursouza · artursouza · commit 4ef888e42598 · 2024-06-26T18:32:24.000-07:00
Signed-off-by: Artur Souza &lt;asouza.pro@gmail.com&gt;
diff --git a/community-membership.md b/community-membership.md
@@ -6,9 +6,9 @@ This doc outlines the responsibilities of contributor roles in Dapr. The Dapr pr
 | **Role**   | **Responsibilities**                                  | **Requirements**                                             | **Defined by**                                               |
 | ---------- | ----------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
 | Member     | Active contributor in the community.  Reviewer of PRs | Sponsored by two approvers or maintainers. Multiple contributions to the project. | Dapr GitHub org member                           |
-| Approver   | Approve accepting contributions                       | Highly experienced and active reviewer and contributor to a subproject. | [CODEOWNERS](https://help.github.com/en/articles/about-code-owners) in GitHub |
-| Core-Maintainer | Set direction and priorities for a subproject         | Demonstrated responsibility and excellent technical judgement for the subproject. | [CODEOWNERS](https://help.github.com/en/articles/about-code-owners), GitHub Team and repo ownership in GitHub |
-| Feature-Maintainer | Set direction and priorities for a subarea of project/repo         | Demonstrated responsibility and excellent technical judgement for the subarea. | [CODEOWNERS](https://help.github.com/en/articles/about-code-owners), GitHub Team and repo ownership in GitHub |
+| Approver   | Approve accepting contributions                       | Highly experienced and active reviewer and contributor to a subproject. | [CODEOWNERS](https://help.github.com/en/articles/about-code-owners), GitHub Team and repository write access in GitHub |
+| Feature Maintainer | Set direction and priorities for a feature or a specialized area of project/repo         | Demonstrated responsibility and excellent technical judgement in the area. | [CODEOWNERS](https://help.github.com/en/articles/about-code-owners), GitHub Team and repository write access in GitHub |
+| Maintainer | Set direction and priorities for a repository         | Demonstrated responsibility and excellent technical judgement for the repository's code base. | [CODEOWNERS](https://help.github.com/en/articles/about-code-owners), GitHub Team and repository ownership in GitHub |
 
 > Note: The Steering & Technical Committee (STC) referred to in this document is described [here](./steering-and-technical-committee-charter.md)
 
@@ -60,8 +60,7 @@ Defined by: Member of the Dapr GitHub organization
 ### Responsibilities and privileges
 
 - Responsive to issues and PRs assigned to them
-- Active owner of code contributed by them (unless ownership is explicitly
-  transferred)
+- Active owner of code contributed by them (unless ownership is explicitly transferred)
   - Code is well tested
   - Tests consistently pass
   - Addresses bugs or issues discovered after code is accepted
@@ -72,7 +71,7 @@ Defined by: Member of the Dapr GitHub organization
 
 ## Approver
 
-Code approvers are able to both review and approve code contributions, as well as help maintainers triage issues and do project management.
+Code approvers should review and approve code contributions, as well as help maintainers triage issues and do project management.
 
 While code review is focused on code quality and correctness, approval is
 focused on holistic acceptance of a contribution including: backwards/forwards
@@ -108,113 +107,118 @@ The following apply to the part of the codebase for which one would be an approv
 - Expected to be responsive to review requests (inactivity for more than 1 month may result in suspension until active again)
 - Mentor contributors and reviewers
 - May approve code contributions for acceptance
-- Inactivity for more than 3 months leads to a removal vote by other maintainers/approvers and not an automatic removal
+- Inactivity for more than 3 months leads to a removal vote by maintainers and not an automatic removal
 
-## Core-Maintainer
+## Feature-maintainer
 
-Core-Maintainers are the technical authority for a subproject in the Dapr org. They *MUST* have demonstrated both good judgement and responsibility towards the health of that subproject. Core Maintainers *MUST* set technical direction and make or approve design decisions for their subproject - either directly or through delegation of these responsibilities.
+Feature-maintainers are the technical authority for a feature or specialized area of the project/repository in the Dapr org. They *MUST* have demonstrated both good judgement and responsibility towards the health of that space. Feature Maintainers can set technical direction and make or approve design decisions for their designated space.
 
-Defined by: GitHub organization ownership, permissions and entry in `CODEOWNERS`
-files.
+Defined by: GitHub write permission in repository and entry in `CODEOWNERS` files.
 
 ### Requirements
 
-The following apply to the subproject for which one would be an owner:
+The following apply to the area (ex: building block API/ Control plane service/ Component provider) for which one would be a feature-maintainer:
 
-- Deep understanding of the technical goals and direction of the subproject
-- Deep understanding of the technical domain (specifically the language) of the
-  subproject
+- Deep understanding of the technical goals and direction of the area.
+- Deep understanding of the technical domain (specifically the language) of the area
 - Sustained contributions to design and direction by doing all of:
   - Authoring and reviewing proposals
-  - Initiating, contributing and resolving discussions (e.g. emails, GitHub issues, meetings)
+  - Initiating, contributing and resolving discussions (Discord discussions, GitHub issues, meetings)
   - Identifying subtle or complex issues in designs and implementation PRs
-- Directly contributed to the subproject through implementation and / or review
-- Aligning with the overall project goals, specifications and design principles defined by the Technical & Steering Committee. Bringing general questions and requests to the discussions as part of specifications project
-- Must have been active for 3 months or more for the given sub-project
-- Inactivity for more than 3 months leads to a removal vote by other maintainers and not an automatic removal
+- Directly contributed to the space through implementation and/or review
+- Must have been active for 3 months or more for the given space
+- Inactivity for more than 3 months leads to a removal vote by the repository maintainers and not an automatic removal.
+
 
 ### Acceptance
 
-New Core-maintainers can be added to the project by a super-majority (two-thirds / 66.66%) vote. Only the Core-maintainers of the repository in which the nomination is applied to have a binding vote, while Core-maintainers from other repositories are on an informed basis via a separate email thread. A potential Core-maintainer may be nominated by an existing Core-maintainer from the repository in which the nomination is applied to. A vote is conducted in private between the current Core-maintainers over the course of a one week voting period. At the end of the week, votes are counted and a pull request is made on the repo adding the new core-maintainer to the CODEOWNERS file.
+New feature-maintainers can be added to the project by a super-majority (two-thirds / 66.66%) vote. Only the maintainers (not feature-maintainers) of the repository in which the nomination is applied have a binding vote, while maintainers from other repositories are on an informed basis via a separate email thread.
+
+A potential feature-maintainer may be nominated by an existing maintainer (not feature-maintainers) from the repository in which the nomination is applied to. A vote is conducted in private between the current maintainers over the course of a one week voting period. At the end of the week, votes are counted, and a pull request is made on the repo adding the new feature-maintainer to the feature-maintainers.md file.
+
+Feature-maintainers MUST remain active. Inactivity for more than 3 months leads to a removal vote by maintainers and not an automatic removal
 
-Core-Maintainers for new repositories can be nominated by any member of the steering committee and voted on in a steering committee meeting.
-Single Core-Maintainers of a repository can nominate a new Core-Maintainer and *MUST* inform the steering committee of their intention. The Core-Maintainer can be approved if no objections have been raised in a period of one week.
+A feature-maintainer may step down by submitting an issue stating their intent.
 
-A Core-Maintainer may step down by submitting an issue stating their intent.
+Former feature-maintainers of a repository must be mentioned in the repository's README.md file, containing their name and GitHub handle under a section called "Emeritus feature-maintainers".
+
+### Example of feature areas in DAPR Runtime repo:
+
+- Workflow
+- Distributed Scheduler
+- Placement
+- Actors
+- PubSub
+- Tracing
 
 ### Responsibilities and privileges
 
-The following apply to the subproject(repos) for which one would be an owner:
+The following applies to the area(ex: building block API/ Control plane service/ Component provider) for which the feature-maintainer would be an owner:
 
-- Make and approve technical design decisions for the subproject
-- Set technical direction and priorities for the subproject
-- Define milestones and releases
-  - Decides on when PRs are merged to control the release scope
-- Mentor and guide approvers and contributors to the subproject
-- Escalate *approver* and *maintainer* workflow concerns (i.e. responsiveness, availability, and general contributor community health) to the TC
-- Ensure continued health of subproject:
+- Make and approve technical design decisions for the area
+- Set technical direction and priorities for the area.
+- Define milestones and releases working along with the maintainers
+- Decides on when PRs are merged to control the release scope
+- Mentor and guide approvers and contributors of the area
+- Escalate approver and maintainer workflow concerns. (For example responsiveness, availability, and general contributor community health) to the STC
+- Ensure continued health of area:
   - Adequate test coverage to confidently release
-  - Tests are passing reliably (i.e. not flaky) and are fixed when they fail
+  - Tests are passing reliably (not flaky) and are fixed when they fail.
+  - Work with other feature-maintainers & maintainers to maintain the project's overall health and success holistically.
+- Membership tracked in feature-maintainer.md entry and scoped to a area.
+- Must maintain components, review, and approve proposals for enhancing areas falling under the user area.
+- Actively participate in issue triages and PR reviews
+- Set milestone priorities for the areas working with the repo maintainers.
 - Ensure a healthy process for discussion and decision making is in place
-- Work with other maintainers to maintain the project's overall health and success holistically
 
-Core-Maintainers *MUST* remain active. If they are unresponsive for >3 months, they will be automatically removed unless a super-majority of the other repository maintainers agrees to extend the period to be greater than 3 months.
+## Maintainer
 
-## Feature-Maintainer
-
-Feature-Maintainers are the technical authority for a subarea of the project/repo in the Dapr org. They *MUST* have demonstrated both good judgement and responsibility towards the health of that subarea. Feature-maintainers can set technical direction and make or approve design decisions for their subarea - either directly or through delegation of these responsibilities.
+Maintainers are the technical authority for a repository in the Dapr org. They *MUST* have demonstrated both good judgement and responsibility towards the health of that repository. Maintainers *MUST* set technical direction and make or approve design decisions for their repository - either directly or through delegation of these responsibilities to approvers or feature maintainers.
 
 Defined by: GitHub organization ownership, permissions and entry in `CODEOWNERS`
 files.
 
 ### Requirements
 
-The following apply to the area(ex: building block API/ Control plane service/ Component provider) for which one would be a Feature-maintainer:
+The following apply to the repository for which one would be an owner:
 
-- Deep understanding of the technical goals and direction of the area.
-- Deep understanding of the technical domain (specifically the language) of the area
+- Deep understanding of the technical goals and direction of the subproject
+- Deep understanding of the technical domain (specifically the language) of the
+  subproject
 - Sustained contributions to design and direction by doing all of:
   - Authoring and reviewing proposals
-  - Initiating, contributing and resolving discussions  For example Discord discussions,  GitHub issues, meetings)
+  - Initiating, contributing and resolving discussions (e.g. emails, GitHub issues, meetings)
   - Identifying subtle or complex issues in designs and implementation PRs
-- Directly contributed to the subarea through implementation and / or review
-- Must have been active for 3 months or more for the given sub-area
-- Inactivity for more than 3 months leads to a removal vote by the repo maintainers and not an automatic removal
-
+- Directly contributed to the subproject through implementation and / or review
+- Aligning with the overall project goals, specifications and design principles defined by the Technical & Steering Committee. Bringing general questions and requests to the discussions as part of specifications project
+- Must have been active for 3 months or more for the given sub-project
+- Inactivity for more than 3 months leads to a removal vote by other maintainers and not an automatic removal
 
 ### Acceptance
 
-  New Feature-Maintainers can be added to the project by a super-majority (two-thirds / 66.66%) vote. Only the Core-maintainers of the repository in which the nomination is applied have a binding vote, while maintainers from other repositories are on an informed basis via a separate email thread.
-
-  A potential feature-maintainer may be nominated by an existing Core-Maintainer from the repository in which the nomination is applied to. A vote is conducted in private between the current maintainers over the course of a one week voting period. At the end of the week, votes are counted, and a pull request is made on the repo adding the new feature-maintainer to the feature-maintainers.md file.
+New maintainers can be added to the project by a super-majority (two-thirds / 66.66%) vote. Only the maintainers of the repository in which the nomination is applied to have a binding vote, while maintainers from other repositories are on an informed basis via a separate email thread. A potential maintainer may be nominated by an existing maintainer from the repository in which the nomination is applied to. A vote is conducted in private between the current maintainers over the course of a one week voting period. At the end of the week, votes are counted and a pull request is made on the repo adding the new maintainer to the CODEOWNERS file.
 
-  Feature-Maintainers MUST remain active. If they are unresponsive for >3 months, they will be automatically removed unless a super-majority of the other repository maintainers agrees to extend the period to be greater than 3 months.
+Maintainers for new repositories can be nominated by any member of the steering committee and voted on in a steering committee meeting.
+Single maintainers of a repository can nominate a new maintainer and *MUST* inform the steering committee of their intention. A new maintainer can be approved if no objections have been raised in a period of one week.
 
-  A feature-maintainer may step down by submitting an issue stating their intent.
+A maintainer may step down by submitting an issue stating their intent.
 
-### Example of Feature Maintainers in DAPR Runtime repo:
-
-| **Subarea**   | **Name**                                  |**GH Handle**|
-| ---------- | ---------------------------------------------|-------------| 
-| Workflow    | Chris Gilum                                 |cgillum      | 
-| Control Plane Service(mTLS)| Josh V                       |JoshVanL     |
+Former maintainers of a repository must be mentioned in the repository's README.md file, containing their name and GitHub handle under a section called "Emeritus maintainers".
 
 ### Responsibilities and privileges
 
-The following applies to the area(ex: building block API/ Control plane service/ Component provider) for which the feature-maintainer would be an owner:
+The following apply to the subproject(repos) for which one would be an owner:
 
-- Make and approve technical design decisions for the area
-- Set technical direction and priorities for the area.
-- Define milestones and releases working along with the maintainers
-- Decides on when PRs are merged to control the release scope
-- Mentor and guide approvers and contributors of the area
-- Escalate approver and maintainer workflow concerns. (For example responsiveness, availability, and general contributor community health) to the STC
-- Ensure continued health of area:
-- Adequate test coverage to confidently release
-- Tests are passing reliably (not flaky) and are fixed when they fail.
-- Work with other feature-maintainers & Core-maintainers to maintain the project's overall health and success holistically.
-- Membership tracked in feature-maintainer.md entry and scoped to a area.
-- Must maintain components, review, and approve proposals for enhancing areas falling under the user area.
-- Actively participate in issue triages and PR reviews
-- Set milestone priorities for the areas working with the repo maintainers.
+- Make and approve technical design decisions for the subproject
+- Set technical direction and priorities for the subproject
+- Define milestones and releases
+  - Decides on when PRs are merged to control the release scope
+- Mentor and guide approvers and contributors to the subproject
+- Escalate *approver* and *maintainer* workflow concerns (i.e. responsiveness, availability, and general contributor community health) to the TC
+- Ensure continued health of subproject:
+  - Adequate test coverage to confidently release
+  - Tests are passing reliably (i.e. not flaky) and are fixed when they fail
 - Ensure a healthy process for discussion and decision making is in place
+- Work with other maintainers to maintain the project's overall health and success holistically
+
+Maintainers *MUST* remain active. If they are unresponsive for >3 months, a maintainer might start a removal voting process, requiring a super-majority of the other maintainers of the given repository or STC to approve removal.
