[Graduation] Kubeflow Graduation Application

[andreyvelich]

Review Project Moving Level Evaluation

• I have reviewed the TOC's moving level readiness triage guide, ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed.

Kubeflow Graduation Application

v1.6
This template provides the project with a framework to inform the TOC of their conformance to the Graduation Level Criteria.

Project Repo(s): https://github.com/kubeflow
Project Site: https://www.kubeflow.org/
Sub-Projects:

• Kubeflow Spark Operator
• Kubeflow Notebooks
• Kubeflow Trainer
• Kubeflow Katib
• Kubeflow Model Registry
• Kubeflow Pipelines

Communication: CNCF Slack https://www.kubeflow.org/docs/about/community/#slack-channels

Project points of contacts:
Public mailing list: kubeflow-discuss@googlegroups.com
Private Kubeflow Sterring Committee mailing list: ksc@kubeflow.org

• (Post Graduation only) Book a meeting with CNCF staff to understand project benefits and event resources.

In progress

Graduation Criteria Summary for Kubeflow

Application Level Assertion

• This project is currently Incubating, accepted on 2023-07-23, and applying to Graduate.

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:

Kubeflow is used by thousands of organizations worldwide with over 9M downloads per month

We maintain a best-effort list of adopters for Kubeflow Projects:

• https://github.com/kubeflow/community/blob/master/ADOPTERS.md
• https://github.com/kubeflow/spark-operator/blob/master/ADOPTERS.md
• https://github.com/kubeflow/notebooks/blob/main/ADOPTERS.md
• https://github.com/kubeflow/trainer/blob/master/ADOPTERS.md
• https://github.com/kubeflow/katib/blob/master/ADOPTERS.md
• https://github.com/kubeflow/model-registry/blob/main/ADOPTERS.md
• https://github.com/kubeflow/pipelines/blob/master/ADOPTERS.md

Application Process Principles

Suggested

N/A

Required

• Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.

  • TAG provides insight/recommendation of the project in the context of the landscape
    • TAG Runtime - Presentation 21-01-2021: https://youtu.be/S6N8ARZZcGs
    • TAG Runtime and TOC AI Initiatives - Presentation 24-11-2024: https://youtu.be/u4Mf3Jh8v2E?t=2243

• All project metadata and resources are vendor-neutral.

  • Kubeflow governance limits the representation of individual organizations in the Steering Committee and Working Groups.
  • All project communication is vendor neutral.
  • Kubeflow governance details.
  • Kubeflow Steering Committee guideline.

• Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.

  • Acknowledged during this application (September 2025).

• Due Diligence Review.

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria.

• Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.
  • Kubeflow docs: https://www.kubeflow.org/docs/
  • Introduction docs: https://www.kubeflow.org/docs/started/introduction/
  • Installation docs: https://www.kubeflow.org/docs/started/installing-kubeflow/
  • Community: https://www.kubeflow.org/docs/about/community/
  • Due Diligence for Kubeflow Incubation

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.

Suggested

• Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.
  • Governance revised multiple times started from 2019 with the WG formation
  • As of 2023 Kubeflow community performed two elections for Kubeflow Steering Committee (KSC)
  • As of 2024 KSC enforced rule to limit number sits for one organization

Required

• Clear and discoverable project governance documentation.

  • Kubeflow governance details: https://www.kubeflow.org/docs/about/governance/
  • Kubeflow community docs: https://github.com/kubeflow/community

• Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

  • KSC charter is updated: https://github.com/kubeflow/community/blob/master/KUBEFLOW-STEERING-COMMITTEE.md#charter
  • Elections are tracked here: https://github.com/kubeflow/community/tree/master/elections
  • WG meetings are up-to-date: https://www.kubeflow.org/docs/about/community/#list-of-available-meetings

• Governance clearly documents vendor-neutrality of project direction.

  • Maximum of one organization can be on KSC
  • Maximum of one organization can be on Kubeflow Outreach Committee (KOC)

• Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

  • KSC elections are explained in this doc
  • For each year community maintain eligible candidates.
  • Voting procedure is explain in the KSC doc.
  • For major features Kubeflow community follow the Kubeflow Enhancement Proposal (KEP) process.
  • If open source projects want to become a Kubeflow sub-project, they should fill an application.

• Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

  • Kubeflow membership describes the contributor roles in the community.
  • Working Groups follow the lifecycle for creation and retirement.

• Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).

  • It is explained here: https://www.kubeflow.org/docs/about/membership/

• Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.

  • Project leads constantly add and remove maintainers. For example
    • Kubeflow Pipelines: add new KFP maintainers kubeflow/pipelines#12059
    • Kubeflow Trainer: Nominate @Electronic-Waste as approver and @astefanutti as reviewer kubeflow/trainer#2659
    • Kubeflow Model Registry: OWNERS: add Al-Pragliola as approvers kubeflow/model-registry#1153

• Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

  • KSC members
  • KOC members
  • WG chairs and leads
  • Maintainers with OWNERs files

• A number of active maintainers which is appropriate to the size and scope of the project.

  • We have ~ 1500 active contributors

• Project maintainers from at least 2 organizations that demonstrates survivability.

  • Maintainers cover > 10 organizations

• Code and Doc ownership in Github and elsewhere matches documented governance roles.

  • We use prow and tide to define ownership in GitHub. Access to the repos are given by using this YAML file.

• Document adoption and adherence to the CNCF Code of Conduct or the project's CoC which is based off the CNCF CoC and not in conflict with it.

  • Kubeflow follows the CNCF Code of Conduct: https://www.kubeflow.org/docs/about/contributing/#follow-the-code-of-conduct
  • Kubeflow meeting hosts always mention this before the community calls begin.

• CNCF Code of Conduct is cross-linked from other governance documents.

  • https://www.kubeflow.org/docs/about/governance/#1-cncf

• All subprojects, if any, are listed.

  • Kubeflow Spark Operator
  • Kubeflow Notebooks
  • Kubeflow Trainer
  • Kubeflow Katib
  • Kubeflow Model Registry
  • Kubeflow Pipelines

• If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

  • Kubeflow projects are governed by the Kubeflow WGs and the KSC. Open source projects may become Kubeflow subprojects if they complete the required application and receive approval through a KSC vote. WG members have the authority to remove or consolidate existing Kubeflow subprojects with the final vote of KSC.

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.

Suggested

• Contributor ladder with multiple roles for contributors.
  • Check the Kubeflow community membership.

Required

• Clearly defined and discoverable process to submit issues or changes.

  • Submit issue: https://www.kubeflow.org/docs/about/contributing/#starter-issues
  • KEP process: https://github.com/kubeflow/community/tree/master/proposals

• Project must have, and document, at least one public communications channel for users and/or contributors.

  • Kubeflow uses the CNCF slack: https://www.kubeflow.org/docs/about/community/#slack-channels
  • Kubeflow subprojects have dedicated Slack channels:
    • #kubeflow-spark-operator
    • #kubeflow-notebooks
    • #kubeflow-trainer
    • #kubeflow-katib
    • #kubeflow-model-registry
    • #kubeflow-pipelines

• List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.

  • Kubeflow subprojects have dedicated Slack channels
  • #kubeflow-contributors Slack channel is used for developer communications.
  • #kubeflow-announcements Slack channel is used for user announcements.
  • Kubeflow KSC has private mailing list for maintainers, users asks, and for security reports: ksc@kubeflow.org
  • Kubeflow has dedicated mailing list for user announcements and questions: kubeflow-discuss@googlegroups.com
  • Kubeflow community also maintain various social media:
    • LinkedIn: https://www.linkedin.com/company/kubeflow/
    • X: https://x.com/kubeflow
    • BlueSky: https://bsky.app/profile/kubefloworg.bsky.social
    • The main YouTube Channel: https://www.youtube.com/@Kubeflow
    • YouTube channel for meeting recordings: https://www.youtube.com/@KubeflowCommunity

• Up-to-date public meeting schedulers and/or integration with CNCF calendar.

  • Kubeflow calendar for WGs calls and community meetings: https://www.kubeflow.org/docs/about/community/#list-of-available-meetings

• Documentation of how to contribute, with increasing detail as the project matures.

  • Contributing guidelines for all Kubeflow projects are described here: https://www.kubeflow.org/docs/about/contributing/
  • Each Kubeflow subproject also maintains its own specific guidelines in their GitHub repositories:
    • https://github.com/kubeflow/spark-operator/blob/master/CONTRIBUTING.md
    • https://github.com/kubeflow/notebooks/blob/main/CONTRIBUTING.md
    • https://github.com/kubeflow/trainer/blob/master/CONTRIBUTING.md
    • https://github.com/kubeflow/katib/blob/master/CONTRIBUTING.md
    • https://github.com/kubeflow/model-registry/blob/main/CONTRIBUTING.md
    • https://github.com/kubeflow/pipelines/blob/master/CONTRIBUTING.md

• Demonstrate contributor activity and recruitment.

  • Kubeflow projects have ~ 1,500 active contributors from ~ 280 organizations: https://insights.linuxfoundation.org/project/kubeflow/contributors?timeRange=past365days&start=2024-07-15&end=2025-07-15&widget=active-contributors
  • Active contributors have been promoted to project owners, e.g. Nominate @Electronic-Waste as approver and @astefanutti as reviewer kubeflow/trainer#2659
  • Kubeflow DevStat

Engineering Principles

• Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This requirement may also be satisfied by completing a General Technical Review.

  • General Technical Review was completed on 01-09-2025, and can be discovered at feat(docs): Kubeflow General Technical Review kubeflow/community#900
  • Google document was initially reviewed by CNCF

• Document what the project does, and why it does it - including viable cloud native use cases. This requirement may also be satisfied by completing a General Technical Review.

  • General Technical Review was completed on 01-09-2025, and can be discovered at feat(docs): Kubeflow General Technical Review kubeflow/community#900

• Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

  • Each working group defines and agrees on the features for each release. The release cadence for
    each working group varies according to community agreement among the working groups.
  • Kubeflow subprojects maintain its own ROADMAP in their GitHub repositories
    • Kubeflow Trainer
    • Kubeflow Spark Operator
    • Kubeflow Katib
    • Kubeflow Model Registry
    • Kubeflow Pipelines
    • Kubeflow Notebooks

• Roadmap change process is documented.

  • Community-wide changes are proposed as Kubeflow Enhancement proposals (KEPs) in the kubeflow/community repository.
  • Changes to the Kubeflow subprojects are proposed in their repositories, e.g. https://github.com/kubeflow/trainer/tree/master/docs/proposals

• Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This requirement may also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.

  • General Technical Review was completed on 01-09-2025, and can be discovered at feat(docs): Kubeflow General Technical Review kubeflow/community#900

• Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:

  • Release expectations (scheduled or based on feature implementation). Each WG may choose its own cadence for releases based on their priorities. All Kubeflow subprojects must follow the semantic versioning.
  • Tagging as stable, unstable, and security related releases - Kubeflow define multiple criteria for feature stability (stable, beta, alpha). It is mostly enforce by API versions, but can vary for each WG. More information is described here.
  • Information on branch and tag strategies - Kubeflow subprojects maintain release branches and tags.
  • Branch and platform support and length of support - Kubeflow subprojects maintain release branches for the most recent two minor releases. Applicable fixes, including security fixes, may be backported to those two release branches, depending on severity and feasibility. For more info, see the security policy document.
  • Artifacts included in the release - Each Kubeflow WG creates GitHub releases with artifacts if that is required. For example, check the Kubeflow Trainer release or the Kubeflow Spark Operator release.
  • Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out - LTS is defined in the security policy documents. Kubeflow subproject releases are announced via Kubeflow social medias and communication channels.

• History of regular, quality releases.

  • Kubeflow subprojects have long history of releases, e.g. Kubeflow Trainer: https://github.com/kubeflow/trainer/releases
  • Kubeflow AI reference platform releases history can be found here: https://www.kubeflow.org/docs/kubeflow-platform/releases/

Security

Note: this section may be augmented by a joint-assessment performed by TAG Security and Compliance.

Suggested

• Achieving OpenSSF Best Practices silver or gold badge. - In Progress

  • Kubeflow Katib: https://www.bestpractices.dev/projects/9941
  • Kubeflow Trainer: https://www.bestpractices.dev/projects/10435

Required

• Clearly defined and discoverable process to report security issues.

  • Kubeflow Spark Operator security policy: https://github.com/kubeflow/spark-operator/blob/master/SECURITY.md
  • Kubeflow Notebooks security policy: https://github.com/kubeflow/notebooks/blob/master/SECURITY.md
  • Kubeflow Trainer security policy: https://github.com/kubeflow/trainer/blob/master/SECURITY.md
  • Kubeflow Katib security policy: https://github.com/kubeflow/katib/blob/master/SECURITY.md
  • Kubeflow Model Registry security policy: https://github.com/kubeflow/model-registry/blob/main/SECURITY.md
  • Kubeflow Pipelines security policy: https://github.com/kubeflow/pipelines/blob/master/SECURITY.md

• Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)

  • Kubeflow org membership and repositories ACLs are controlled via GitOps here: https://github.com/kubeflow/internal-acls
  • 2FA is required for org members.

• Document assignment of security response roles and how reports are handled.

  • Kubeflow Spark Operator security policy: https://github.com/kubeflow/spark-operator/blob/master/SECURITY.md
  • Kubeflow Notebooks security policy: https://github.com/kubeflow/notebooks/blob/master/SECURITY.md
  • Kubeflow Trainer security policy: https://github.com/kubeflow/trainer/blob/master/SECURITY.md
  • Kubeflow Katib security policy: https://github.com/kubeflow/katib/blob/master/SECURITY.md
  • Kubeflow Model Registry security policy: https://github.com/kubeflow/model-registry/blob/main/SECURITY.md
  • Kubeflow Pipelines security policy: https://github.com/kubeflow/pipelines/blob/master/SECURITY.md

• Document Security Self-Assessment.

  • Kubeflow Security Self-Assessment: https://github.com/kubeflow/community/blob/master/security/self-assessment.md

• Third Party Security Review. Moderate and low findings from the Third Party Security Review are planned/tracked for resolution as well as overall thematic findings, such as: improving project contribution guide providing a PR review guide to look for memory leaks and other vulnerabilities the project may be susceptible to by design or language choice ensuring adequate test coverage on all PRs.

  • The Third Party Security Review was completed in September 2025. The moderate and low issues are being tracked in a private Slack channel with Kubeflow maintainers. We will link the audit report once it is publicly available.

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

  • Kubeflow Spark Operator: https://www.bestpractices.dev/en/projects/10524
  • Kubeflow Katib: https://www.bestpractices.dev/projects/9941
  • Kubeflow Trainer: https://www.bestpractices.dev/projects/10435
  • Kubeflow Model Registry: https://www.bestpractices.dev/en/projects/9937
  • Kubeflow Pipelines: https://www.bestpractices.dev/en/projects/9938
  • Kubeflow Notebooks: https://www.bestpractices.dev/en/projects/9942

Ecosystem

Suggested

N/A

Required

• Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

  • https://github.com/kubeflow/community/blob/master/ADOPTERS.md
  • https://github.com/kubeflow/spark-operator/blob/master/ADOPTERS.md
  • https://github.com/kubeflow/notebooks/blob/main/ADOPTERS.md
  • https://github.com/kubeflow/trainer/blob/master/ADOPTERS.md
  • https://github.com/kubeflow/katib/blob/master/ADOPTERS.md
  • https://github.com/kubeflow/model-registry/blob/main/ADOPTERS.md
  • https://github.com/kubeflow/pipelines/blob/master/ADOPTERS.md

• Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)

  • The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.

• TOC verification of adopters.

  • Pending TOC

• Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.

  • Kubeflow subprojects use and integrate with many projects from CNCF ecosystem including Kubernetes, Argo Workflow, Istio, Cert-Manager, KServe, JobSet, Kueue, Dex, Knative, Volcano, and others. Additionally, Kubeflow uses many non-CNCF projects from AI ecosystem: PyTorch, DeepSpeed, JAX, Jupyter, Apache Spark, Apache Arrow, Apache DataFusion, Horovod, MLX, XGBoost, HuggingFace, and many others.

Adoption

Adopter 1 - Slalom Build/Healthcare

September 2022

Adopter 2 - Capital One/Finance

September 2019

Adopter 3 - CERN/Academic Institutions

September 2019

[shivaylamba]

this is great!