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

Updating membership_policy to inc removal of reviewer/approvers/chairs #365

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+25 −3
Open

Updating membership_policy to inc removal of reviewer/approvers/chairs #365

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
28 changes: 25 additions & 3 deletions membership_policy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -162,7 +162,7 @@ The KubeVirt project is organized primarily into SIGs, each with a common purpos

## SIG Subproject Lead

Specific work efforts within SIGs can be divided into subprojects. A SIG Subproject Lead is required to help guide and coordinate the subproject.
Specific work efforts within SIGs can be divided into subprojects. A SIG Subproject Lead is required to help guide and coordinate the subproject.

### Requirements

Expand Down Expand Up @@ -208,7 +208,11 @@ Working groups are primarily used to facilitate topics of discussion that cross
* Gives updates to respective sponsoring SIG Chairs
* The broader community

## Inactive members
## Inactivity

Impermanence is one of the true constants in life: no one is expected to be with the project forever.

### Inactive members

[_Members are continuously active contributors in the community._](#member)

Expand All @@ -225,7 +229,7 @@ will be removed from the KubeVirt GitHub Organization and will be required to
go through the org membership process again after re-familiarizing themselves
with the current state.

### How inactivity is measured
#### How inactivity for members is measured

Inactive members are defined as members of the KubeVirt Organization
with **no** contributions within the KubeVirt organization within 12 months.
Expand All @@ -239,6 +243,24 @@ After an extended period away from the project with no activity
those members would need to re-familiarize themselves with the current state
before being able to contribute effectively.

### Inactive Reviewers/Approvers/Chairs/Leads

Reviewers, approvers, chairs and leads are pillars of the community and are fundamental to maintaining the momentum of the project.
Considering that they have elevated permissions and responsibilities in the project, their active engagement with the project is greatly appreciated.

If a reviewer and/or approver steps down from their position in a repository or the project entirely, we trust that they will notify the community and create PRs removing them as reviewers/approvers in the applicable repositories.
This will help others identify and grow into the role so as to not leave a gap for any length of time.
It will also ensure they are not erroneously tagged to review/approve PRs, which is both an inconvenience to them but also an obstacle for the project.

When a SIG or WG Chair or Subproject Lead needs to step down from their position, it is expected that they work with the SIG/Subproject/WG to identify and mentor a willing candidate to grow into the role.
They should then open a PR to replace them in [sigs.yaml], and move themselves to emeritus status (if applicable).

A reviewer/approver/chair/lead may also be demoted or removed from their role if they are inactive in their area for 6 months or more.
Copy link
Contributor

@dhiller dhiller Dec 10, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

I think we also should think about the case of a "vanishing" person and their replacement. In that case there's no candidate, so the impacted group or the community should select one.

This could happen maybe by approaching the candidate - either by maintainers of the affected group or the project maintainers in the worst case - and then suggesting them to the group or community in a PR against the sigs.yaml. A quorum of people with authority should then be enough to accept the suggestion.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1.
In general I like the idea of having an "escape hatch" to such defined policies. After all, it makes sense that due to circumstances sometimes someone will vanish with no notice and won't have the time to fulfill this process or even communicate the situation. In such a scenario, I would say that if the majority of SIG chairs vote to remove them because they know they won't be active for the near future, there is no need to wait for 6 months just to get the "proof" of inactiveness.

No policy can replace common sense 100%, but IMO is mostly there to serve as a general guideline.


#### How inactivity for Reviewers/Approvers/Chairs/Leads is measured

The KubeVirt community repo has a [project activity tool](https://github.com/kubevirt/community/blob/main/generators/cmd/contributions/README.md) that can be used to demonstrate that a reviewer/approver has been inactive for 6 months.

[CNCF DevStats project]: https://kubevirt.devstats.cncf.io/d/48/users-statistics-by-repository-group?orgId=1&from=now-1y&to=now&var-period=w&var-metric=activity&var-repogroup_name=All&var-users=All
[OWNERS_ALIASES]: https://github.com/kubevirt/kubevirt/tree/main/OWNERS_ALIASES
[sigs.yaml]: ./sigs.yaml