Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update Feature Maintainer role definition #422

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Update Feature Maintainer role definition #422

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e15faf9
Feature Maintainer definition
rabollin Dec 21, 2023
a28131e
Merge branch 'dapr:master' into Featuremaintainer
rabollin Jan 25, 2024
e7e9a5a
review comments
rabollin Jan 25, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
75 changes: 67 additions & 8 deletions community-membership.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be just "maintainer"?

| 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 |
rabollin marked this conversation as resolved.
Show resolved Hide resolved

> Note: The Steering & Technical Committee (STC) referred to in this document is described [here](./steering-and-technical-committee-charter.md)

Expand Down Expand Up @@ -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.
Expand All @@ -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

Expand All @@ -157,5 +158,63 @@ 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would avoid the expression "sub area" and just call "area".


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:

- 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)
- 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 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.

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:

| **Subarea** | **Name** |**GH Handle**|
| ---------- | ---------------------------------------------|-------------|
| Workflow | Chris Gilum |cgillum |
| Control Plane Service(mTLS)| Josh V |JoshVanL |

### 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:

- 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.
- Ensure a healthy process for discussion and decision making is in place