Workflow:Kubeflow Kubeflow Contributing To Kubeflow
| Knowledge Sources | |
|---|---|
| Domains | Open_Source, Community, Governance |
| Last Updated | 2026-02-13 14:00 GMT |
Overview
Process for contributing code, documentation, or bug fixes to the Kubeflow project through its distributed multi-repository structure and Working Group governance.
Description
This workflow guides new and experienced contributors through the Kubeflow contribution process. Kubeflow uses a distributed repository model where the umbrella repository (kubeflow/kubeflow) serves as the organizational hub, while actual code lives in dedicated sub-project repositories (kubeflow/pipelines, kubeflow/trainer, kubeflow/katib, etc.). Contributions are coordinated through Working Groups that own specific sub-projects, and the overall project is governed by the Kubeflow Steering Committee. This workflow covers identifying the right repository, understanding the contribution guidelines, submitting changes, and engaging with the community.
Usage
Follow this workflow when you want to contribute to any Kubeflow sub-project, whether it is a code change, documentation improvement, bug fix, or feature proposal. This is especially important for first-time contributors who need to understand the distributed repository structure and find the correct place to submit their contribution.
Execution Steps
Step 1: Identify_Target_Repository
Determine which Kubeflow sub-project repository is appropriate for your contribution. The umbrella repository (kubeflow/kubeflow) handles project-level documentation and governance only. Code contributions go to the specific sub-project repository that owns the relevant component.
Key considerations:
- KServe contributions go to kserve/kserve
- Pipeline contributions go to kubeflow/pipelines
- Training contributions go to kubeflow/trainer
- Notebook contributions go to kubeflow/notebooks
- Katib contributions go to kubeflow/katib
- Model Registry contributions go to kubeflow/model-registry
- Platform and manifest contributions go to kubeflow/manifests
- The issue template in kubeflow/kubeflow redirects to the correct sub-project
Step 2: Review_Contribution_Guidelines
Read the contribution guidelines for both the Kubeflow project and the specific sub-project. Each repository may have its own CONTRIBUTING.md, code style requirements, testing expectations, and review process. The central Kubeflow contributor guide on kubeflow.org provides the overarching policies.
Key considerations:
- Review the Kubeflow Contributor Guide at kubeflow.org
- Check the target repository's CONTRIBUTING.md for specific requirements
- Understand the Developer Certificate of Origin (DCO) sign-off requirement
- Familiarize yourself with the Working Group that owns the sub-project
Step 3: Engage_With_Community
Connect with the Kubeflow community before starting significant contributions. Join the Kubeflow Slack channels, attend Working Group meetings, and discuss your proposed changes via GitHub Issues or community forums to get feedback and alignment.
Key considerations:
- Join the Kubeflow Slack workspace for real-time communication
- Attend the relevant Working Group meeting (Tuesdays) for your area
- Create or comment on a GitHub Issue to discuss the change before coding
- For large features, a design document may be required
Step 4: Develop_And_Test
Implement your change following the sub-project's coding standards. Set up the local development environment, write the code or documentation, add appropriate tests, and verify everything passes the CI checks before submitting.
Key considerations:
- Follow the repository's code style and linting rules
- Add unit tests and integration tests as required
- Run the existing test suite locally to catch regressions
- Ensure your commit messages are clear and sign off with DCO
Step 5: Submit_Pull_Request
Open a pull request against the target repository's main branch. Provide a clear description of the change, link to any related issues, and request review from the appropriate Working Group maintainers. Respond to review feedback and iterate until the PR is approved and merged.
Key considerations:
- Reference related GitHub Issues in the PR description
- Request review from the relevant Working Group maintainers
- Address CI failures and reviewer feedback promptly
- PRs require approval from at least one maintainer before merge
- Stale PRs may be closed automatically after 90 days of inactivity