The KubeVirt project is committed to inclusive, vendor-neutral decision making that serves the broader community's interests. The KubeVirt community prioritizes transparency in all discussions and decisions. Our Special Interest Group (SIG), Working Group (WG), and KubeVirt Community meetings are all open for anyone to join and contribute. Details for all of our meetings and events can be found on the KubeVirt calendar.
It is our intention to actively foster a welcoming environment that values all types of contributions across the ecosystem. Enhancing our project's diversity and long-term sustainability through any and all of the following: code and non-code PRs; reviewing and providing feedback on PRs; involvement on our mailing list and/or chat forums; raising bugs and issues; and active participation in meetings, meetups, and conferences.
Active and interested contributors are encouraged to step into positions of responsibility and leadership through our contributor ladder.
| Role | Responsibilities | Requirements | Defined by |
|---|---|---|---|
| Contributor | Adhere to the KubeVirt Code of Conduct | Submit at least one pull request | Active GitHub account |
| Org 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 |
| SIG Chair | Lead a SIG aligned to the goals of the SIG charter | * Can be sig-approver * Highly experienced in SIG matters * Active reviewer & contributor to the project |
sigs.yaml chair entry |
| SIG Subproject Lead | Lead a subproject aligned to the goals of the SIG charter | * sig-reviewer * Highly experienced in SIG subproject matters * Active reviewer & contributor to the project |
sigs.yaml subproject leads entry |
| WG Chair | Lead a WG aligned to the goals of the WG charter | * Highly experienced in WG matters * Active reviewer & contributor to the project |
sigs.yaml WG chairs entry |
| Project Maintainers | Steer the project from the highest level | * Demonstrated leadership in the community See the Governance doc for more details |
MAINTAINERS file |
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 KubeVirt Code of Conduct and by extension 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 of the KubeVirt Github organization 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
- Actively own their contributions (unless ownership is explicitly transferred)
- Contributions are 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 run against their PRs automatically. No /test from other KubeVirt org members needed any more.
- Members can 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.
- Org 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
In exceptional circumstances, such as when a repo is left without sufficient approvers, the project maintainers can pass a majority vote to add approvers that do not fulfill the requirements.
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
The KubeVirt project is organized primarily into SIGs, each with a common purpose of advancing the project with respect to a specific topic, such as Networking or Storage. A SIG Chair is required to help guide and coordinate the SIG.
- Active reviewer for SIG matters for at least 3 months
- Track record of contributions to SIG matters
- Advanced knowledge in SIG subject
- Is an organizer, i.e.
- Ensures that SIG meetings are moderated
- Ensures that meeting notes are captured
- Is a facilitator, i.e.
- Advances SIG topics
- Approves & facilitates the creation of new subprojects
- Operates the SIG
- Updates charter when required
- Updates sigs.yaml SIG entry
- Communicates and coordinates:
- with sponsored WGs
- with other SIGs
- to the broader community
- Claims approver rights in scope, i.e. by
- Creating a sig-approver group in
OWNERS_ALIASES, - Adding a reference to the above in an
OWNERSfile - Adding an
ownersreference in sigs.yaml
- Creating a sig-approver group in
Specific work efforts within SIGs can be divided into subprojects. A SIG Subproject Lead is required to help guide and coordinate the subproject.
- Active reviewer for subproject matters for at least 3 months
- Track record of contributions to subproject matters
- Advanced knowledge in subproject scope
- Creates and maintains a subproject
- Leads within subproject scope, i.e.
- Sets technical direction,
- Makes design decisions
- Mentors other contributors
- Moderates technical discussions and decisions
- Claims approver rights in scope, i.e. by
- Creating a subproject-approver group in
OWNERS_ALIASES - Adding a reference to the above in an
OWNERSfile - Adding an
ownersreference in sigs.yaml
- Creating a subproject-approver group in
Working groups are primarily used to facilitate topics of discussion that cross SIG lines. Working Group Chairs are required to help guide the working group and coordinate with SIG Chairs and the broader community.
- Active reviewer for WG matters for at least 3 months
- Track record of contributions to WG matters
- Advanced knowledge in WG scope
- Is an organizer, i.e.
- Ensures that WG meetings are moderated
- Ensures that meeting notes are captured
- Is a facilitator, i.e.
- Advances exploration of the WG scope
- Fosters collaboration across SIG boundaries related to WG scope
- Operates the WG
- Updates charter when required
- Updates sigs.yaml WG entry
- Communicates and coordinates
- Gives updates to respective sponsoring SIG Chairs
- The broader community
Impermanence is one of the true constants in life: no one is expected to be with the project forever.
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.
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 to remove themselves 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, or if there is a majority vote by the remaining approvers/chairs/leads or maintainers depending on the situation (for instance, if a SIG chair abruptly leaves one remaining SIG chair).
The KubeVirt community repo has a project activity tool that can be used to demonstrate that a reviewer/approver has been inactive for 6 months.