From e15faf95e057c036062fddae4d302919ab3f26bc Mon Sep 17 00:00:00 2001 From: rabollin Date: Fri, 22 Dec 2023 00:39:04 +0530 Subject: [PATCH 1/2] Feature Maintainer definition Signed-off-by: rabollin --- community-membership.md | 81 +++++++++++++++++++++++++++++++++++++---- 1 file changed, 73 insertions(+), 8 deletions(-) diff --git a/community-membership.md b/community-membership.md index 918d430..96ea02e 100644 --- a/community-membership.md +++ b/community-membership.md @@ -7,7 +7,8 @@ This doc outlines the responsibilities of contributor roles in Dapr. The Dapr pr | ---------- | ----------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | | 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 | -| 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 | +| 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 | > Note: The Steering & Technical Committee (STC) referred to in this document is described [here](./steering-and-technical-committee-charter.md) @@ -109,9 +110,9 @@ The following apply to the part of the codebase for which one would be an approv - 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 -## Maintainer +## Core-Maintainer -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. Maintainers *MUST* set technical direction and make or approve design decisions for their subproject - either directly or through delegation of these responsibilities. +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. Defined by: GitHub organization ownership, permissions and entry in `CODEOWNERS` files. @@ -134,12 +135,12 @@ The following apply to the subproject for which one would be an owner: ### Acceptance -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. +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. -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. The maintainer can be approved if no objections have been raised in a period of one week. +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 maintainer may step down by submitting an issue stating their intent. +A Core-maintainer may step down by submitting an issue stating their intent. ### Responsibilities and privileges @@ -157,5 +158,69 @@ The following apply to the subproject(repos) for which one would be an owner: - 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, 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. +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. +## 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. + +Defined by: GitHub organization ownership, permissions and entry in `CODEOWNERS` +files. + +### Requirements + +The following apply to the sub 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 sub area. +- Deep understanding of the technical domain (specifically the language) of the sub area +- 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) + - 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 + + +### Acceptance + + New Feature-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 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 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. 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. + + A feature-maintainer may step down by submitting an issue stating their intent. + +### Example of Feature Maintainers in DAPR Runtime repo: +Sub Area +Person Name +Workflow +Chris Gillum +Control Plane Service(mTLS) +Josh V + +| **Subarea** | **Name** | +| ---------- | ---------------------------------------------| +| Workflow | Chris Gilum | +| Control Plane Service(mTLS)| Josh V | + +### Responsibilities and privileges + +The following applies to the sub 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 sub area +- Set technical direction and priorities for the sub 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 sub area +- Escalate approver and maintainer workflow concerns. (For example responsiveness, availability, and general contributor community health) to the STC +- Ensure continued health of sub 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 sub area. +- MUST maintain components, review, and approve proposals for enhancing areas falling under the user sub area. +- Actively participate in issue triages and PR reviews +- Set milestone priorities for the sub areas or delegate the responsibility to repo maintainers. +- Ensure a healthy process for discussion and decision making is in place From e7e9a5af5b0dcbaf4d31698b628eec619b35691d Mon Sep 17 00:00:00 2001 From: rabollin Date: Thu, 25 Jan 2024 21:08:45 +0530 Subject: [PATCH 2/2] review comments --- community-membership.md | 50 ++++++++++++++++++----------------------- 1 file changed, 22 insertions(+), 28 deletions(-) diff --git a/community-membership.md b/community-membership.md index 96ea02e..60ae167 100644 --- a/community-membership.md +++ b/community-membership.md @@ -137,10 +137,10 @@ The following apply to the subproject for which one would be an owner: 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. -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. +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 Core-maintainer may step down by submitting an issue stating their intent. +A Core-Maintainer may step down by submitting an issue stating their intent. ### Responsibilities and privileges @@ -169,10 +169,10 @@ files. ### Requirements -The following apply to the sub area(ex: building block API/ Control plane service/ Component provider) for which one would be a Feature-maintainer: +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 sub area. -- Deep understanding of the technical domain (specifically the language) of the sub area +- 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 For example Discord discussions, GitHub issues, meetings) @@ -184,43 +184,37 @@ The following apply to the sub area(ex: building block API/ Control plane servic ### Acceptance - New Feature-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 have a binding vote, while maintainers from other repositories are on an informed basis via a separate email thread. + 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 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. + 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. - 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. + 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. A feature-maintainer may step down by submitting an issue stating their intent. ### Example of Feature Maintainers in DAPR Runtime repo: -Sub Area -Person Name -Workflow -Chris Gillum -Control Plane Service(mTLS) -Josh V - -| **Subarea** | **Name** | -| ---------- | ---------------------------------------------| -| Workflow | Chris Gilum | -| Control Plane Service(mTLS)| Josh V | + +| **Subarea** | **Name** |**GH Handle**| +| ---------- | ---------------------------------------------|-------------| +| Workflow | Chris Gilum |cgillum | +| Control Plane Service(mTLS)| Josh V |JoshVanL | ### Responsibilities and privileges -The following applies to the sub area(ex: building block API/ Control plane service/ Component provider) for which the feature-maintainer 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 sub area -- Set technical direction and priorities for the sub area. +- 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 sub area +- 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 sub area: +- 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 sub area. -- MUST maintain components, review, and approve proposals for enhancing areas falling under the user sub area. +- 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 sub areas or delegate the responsibility to repo maintainers. +- Set milestone priorities for the areas working with the repo maintainers. - Ensure a healthy process for discussion and decision making is in place