This document outlines the various responsibilities of contributor roles in KubeVirt.
| Role | Responsibilities | Requirements | Defined by |
|---|---|---|---|
| Contributor | Adhere to the KubeVirt code of conduct | Submit at least one pull request | Active GitHub account |
| Member | Active contributor in the community | * Active contributor * Sponsored by 2 members * Multiple contributions to the project |
KubeVirt GitHub org member |
| Reviewer | Review contributions from others | * Member * History of review and authorship in the project * Sponsored by an approver |
OWNERS_ALIASES file reviewer entry |
| Approver | Approve accepting contributions | * Reviewer * Highly experienced * Active reviewer & contributor to the project Sponsored by 2 approvers |
OWNERS_ALIASES file approver entry |
New contributors should be welcomed to the community by existing members, helped with PR workflow, and directed to relevant documentation and communication channels. All contributors are expected to adhere to the CNCF Code of Conduct.
Established community members are expected to demonstrate their adherence to the principles in this document, familiarity with project organization, roles, policies, procedures, conventions, etc., and technical and/or writing ability. Role-specific expectations, responsibilities, and requirements are enumerated below.
Members are continuously active contributors in the community. They can have issues and PRs assigned to them, participate in community related meetings (e.g. bug scrub), and pre-submit tests are automatically run for their PRs. Members are expected to remain active contributors to the community. Defined by: Member of the KubeVirt GitHub organization
- Enabled two-factor authentication on their GitHub account
- Actively contributing to the project with multiple contributions to the project or community. Contribution may include, but is not limited to:
- Authoring or reviewing PRs on GitHub
- Filing or commenting on issues on GitHub
- Contributing to community discussions (e.g. meetings, Slack, email discussion forums, Stack Overflow)
- GitHub Insight metrics will be reviewed periodically
- Subscribed to kubevirt-dev@googlegroups.com
- Has read the contributor guide
- Actively contributing to the project
- Contributions according to GitHub and/or Kubernetes metrics in the past 90 days.
- Sponsored by 2 org members. Note the following requirements for sponsors:
- Open a PR against the org members section
- Ensure your sponsors are @mentioned on the issue
- Complete every item on the checklist
- Make sure that the list of contributions included is representative of your work on the project.
- Have your sponsoring org members reply confirmation of sponsorship: +1
- Once your sponsors have responded, your request will be reviewed by KubeVirt project approvers. Any missing information will be requested.
Important
After the pull request against the org members section has been merged (see above), an invitation to the KubeVirt GitHub organization will be automatically sent to the new member. The new member needs to accept the invitation to receive member status.
- Responsive to issues and PRs assigned to them
- Responsive to mentions
- Active owner their contributions (unless ownership is explicitly transferred)
- Contribution is well tested
- Tests consistently pass
- Addresses bugs or issues discovered after contribution is accepted
- Members can do /lgtm on open PRs.
- They can be assigned to issues and PRs, and people can ask members for reviews with a /cc @username.
- Tests can be run against their PRs automatically. No /ok-to-test needed.
- Members can do /ok-to-test for PRs that have a needs-ok-to-test label, and use commands like /close to close PRs as well.
!! note Members who frequently contribute are expected to proactively perform reviews and work towards becoming a primary reviewer.
Reviewers are trusted to review contributions for quality and correctness on some part of the project. They are knowledgeable about both the project and engineering principles. Defined by: reviewers entry in an OWNERS file of the KubeVirt project. Note: Acceptance of contributions requires at least one approver in addition to the assigned reviewers. Reviewer Status is scoped to a part of the project.
The following apply to the part of project for which one would be a reviewer in the OWNERS_ALIASES file.
- Member for at least 3 months
- Primary reviewer for at least 5 PRs to the project
- Reviewed or merged at least 20 substantial PRs to the project
- Knowledgeable about the project
- Sponsored by an approver
- With no objections from other approvers
- Done through PR to update the OWNERS file
- May either be self-nominate or nominated by an approver
- The following apply to the part of project for which one would be a reviewer in the OWNERS_ALIASES file.
- Tests are automatically run for PullRequests from members of the KubeVirt GitHub organization
- Reviewer status may be a precondition to accepting L+ contributions
- Responsible for project quality control via reviews
- Focus on quality and correctness, including testing and factoring
- May also review for more holistic issues, but not a requirement
- Expected to be responsive to review requests as per community expectations
- Assigned PRs to review related to project
- Assigned test bugs related to project
- Granted "read access" to KubeVirt repo
- May get a badge on PR and issue comments
Approvers are able to both review and approve contributions. While contribution review is focused on quality and correctness, approval is focused on holistic acceptance of a contribution including: backwards / forwards compatibility, adhering to API and flag conventions, subtle performance and correctness issues, interactions with other parts of the system, etc. Defined by: Approvers entry in an OWNERS file in a repo owned by the KubeVirt project. Approver Status is scoped to a part of the project.
The following apply to the part of project for which one would be an approver in the OWNERS_ALIASES file.
- Reviewer of the project for at least 3 months
- Primary reviewer for at least 10 substantial PRs to the project
- Reviewed or merged at least 30 PRs to the project
- Nominated by an approver
- With no objections from other approvers
- Done through PR to update the top-level OWNERS file
The following apply to the part of project for which one would be an approver in the OWNERS file (for repos using the bot).
- Approver status may be a precondition to accepting contributions
- Demonstrate sound technical judgement
- Responsible for project quality control via reviews
- Focus on holistic acceptance of contribution such as dependencies with other features, backwards / forwards compatibility, API and flag definitions, etc
- Expected to be responsive to review requests as per community expectations
- Mentor contributors and reviewers
- May approve contributions for acceptance
Members are continuously active contributors in the community.
A core principle in maintaining a healthy community is encouraging active participation. It is inevitable that people's focuses will change over time, and they are not expected to be actively contributing forever.
However, being a member of the KubeVirt GitHub organization comes with an elevated set of permissions. These capabilities should not be used by those that are not familiar with the current state of the KubeVirt project.
Therefore, members with an extended period away from the project with no activity 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.
Inactive members are defined as members of the KubeVirt Organization with no contributions within the KubeVirt organization within 12 months. This is measured by the CNCF DevStats project.
Note: Devstats does not take into account non-code contributions. If a non-code contributing member is accidentally removed this way, they may open an issue to quickly be re-instated.
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.