Community Membership

This document outlines the various responsibilities of contributor roles in Kubeflow. Kubeflow is divided into working groups that have stewardship over different subprojects/repositories

Responsibilities for most roles are scoped to these repositories.

New contributors

New contributors should be welcomed to the community by existing members, helped with PR workflow, and directed to the relevant documentation and communication channels.

Established community members

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.

Member

Members are continuously active contributors in the community. They can have issues and PRs assigned to them and tests are automatically run for their PRs. Members are expected to remain active contributors to the community.

Defined by: Member of the Kubeflow GitHub organization

Requirements

• Enabled two-factor authentication on their GitHub account
• Have made at least 2-3 code contributions or non-code contributions to the project or community.
• Have read the contributor guide.
• Sponsored by 2 Kubeflow members. Note the following requirements for sponsors:
• Open an issue with the membership template against the kubeflow/internal-acls repo
  • Ensure your sponsors are @mentioned on the issue
• Open a pull request against the kubeflow/internal-acls repo
  • Complete every item on the checklist (preview the current version of the template)
  • Make sure that the list of contributions included is representative of your work on the project.
• Have your sponsoring reviewers reply confirmation of sponsorship
• Once your sponsors have responded, your request will be reviewed by the Kubeflow team. Any missing information will be requested

Responsibilities

• Responsive to issues and PRs assigned to them
• Active participants in the Kubeflow community by participating in:
  • Working Group Meetings
  • Slack Discussions
  • Project Discussions
• Responsive to mentions of any teams they may be members of
• Active owner of code they have contributed (unless ownership is explicitly transferred)
  • Code is well tested
  • Tests consistently pass
  • Addresses bugs or issues discovered after code is accepted
• Subscribed to https://groups.google.com/g/kubeflow-discuss

Privileges

• 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.
• They are eligible to be appointed as a Kubeflow release manager
• 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. A complete list of commands can be found in the Prow documentation

Reviewer

Reviewers are able to review code for quality and correctness on some part of a subproject. They are knowledgeable about both the codebase and software engineering principles.

Defined by: reviewers entry in an OWNERS file in a repo owned by the Kubeflow organization.

Reviewer status can be scoped to either parts of the codebase or the root directory for the entire codebase.

Requirements

The following apply to the part of codebase for which one would be a reviewer in an OWNERS file.

• member for at least 3 months
• Primary reviewer for at least 5 PRs to the codebase
• Reviewed or merged at least 15 substantial PRs to the codebase
• Knowledgeable about the codebase
• Active engagement with the commmunity by answering user questions in GitHub issues and Slack
• Sponsored by a subproject approver
  • With no objections from other approvers
  • Done through PR to update the OWNERS file
• May either self-nominate or be nominated by an approver in this subproject

The following apply to the part of codebase for which one would be a reviewer in an OWNERS file.

Responsibilities

• All responsiblities that community members have
• Responsible for project quality control via code reviews
  • Focus on code 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
• Expected to actively engage with the community by answering questions in GitHub issues and Slack
• Assigned PRs to review related to subproject of expertise
• Assigned test bugs related to subproject of expertise

Privileges

• All Privileges that community members have
• Code reviewer status may be a precondition to accepting large code contributions
• May get a badge on PR and issue comments

Approver

Code approvers are able to both review and approve code contributions. While code review is focused on code 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, overall code test coverage, etc.

Defined by: approvers entry in an OWNERS file in a repo owned by the Kubeflow organization.

Approver status can be scoped to either parts of the codebase or the root directory for the entire codebase.

Requirements

The following apply to the part of codebase for which one would be an approver in an OWNERS file.

• Have met the responsibilities of the Reviewer role (as defined above) of the codebase for at least 3 months
• Primary reviewer for at least 10 substantial PRs to the codebase
• Reviewed or merged at least 30 PRs to the codebase
• Nominated by a WG Lead or Chair
  • With no objections from other Leads or Chairs
  • Done through PR to update the relevant OWNERS file

Responsibilities

The following apply to the part of codebase for which one would be an approver in an OWNERS file.

• All responsibilities that reviewers have
• Approver status may be a precondition to accepting large architectural contributions
• Demonstrate sound technical judgement
• Responsible for project quality control via code 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
• Expected to be responsive to merge requests for pull requests when reviewed
• Mentor contributors and reviewers

Privileges

• All privileges that reviewers have
• May approve code contributions for acceptance

Inactive members

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 one of the Kubeflow GitHub organizations 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 Kubeflow organization.

Therefore members with an extended period (1 year) away from the organization with no activity will be removed from the Kubeflow GitHub Organizations and will be required to go through the org membership process again after re-familiarizing themselves with the current state.

How inactivity is measured

Inactive members are defined as members of one of the Kubeflow Organizations with no technical and non-technical contributions across any organization within 12 months. DevStats offers an easy way to determine contributions to Kubeflow

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.

Credit

This set of guidelines is heavily inspired by the Kubernetes membership guidelines.