Principle:Kubeflow Kubeflow Contribution Guidelines
| Knowledge Sources | |
|---|---|
| Domains | Contributor Onboarding, Open Source Governance, Documentation |
| Last Updated | 2026-02-13 00:00 GMT |
Overview
Contribution guidelines establish the canonical set of rules, processes, and expectations that contributors must follow when submitting patches and contributions to an open-source project.
Description
In the Kubeflow project, the contribution guidelines are maintained as a centralized, authoritative document hosted on the official Kubeflow website at https://www.kubeflow.org/docs/about/contributing/. Rather than duplicating this information across every repository, Kubeflow uses a lightweight CONTRIBUTING.md file in each repository that serves as a redirect pointer to the canonical guide.
This design follows the single source of truth pattern: instead of maintaining parallel contribution documents that inevitably drift out of sync, the repository-level CONTRIBUTING.md contains only a brief welcome message and a link to the full guide. GitHub automatically surfaces CONTRIBUTING.md in the repository UI (e.g., when contributors open issues or pull requests), making it the natural first touchpoint. By keeping this file minimal and pointing to the website, the project ensures all contributors receive consistent, up-to-date guidance regardless of which repository they enter through.
The canonical guide covers topics including the Developer Certificate of Origin (DCO) sign-off requirement, coding standards, pull request workflow, review process, and community norms.
Usage
Apply this principle when:
- A new contributor is looking for guidance on how to participate in the Kubeflow project.
- Setting up a new Kubeflow sub-project repository that needs a
CONTRIBUTING.mdfile. - Verifying that contribution processes are consistent across the organization.
- Onboarding contributors who may be unfamiliar with the DCO, PR workflow, or review expectations.
Theoretical Basis
The contribution guidelines principle follows a layered information architecture:
- Repository-level entry point: The
CONTRIBUTING.mdfile in each repository serves as the first touchpoint. GitHub renders this file prominently when contributors interact with the repository (creating issues, opening PRs). Its role is purely navigational: welcome the contributor and direct them to the full guide. - Canonical guide on kubeflow.org: The full contributor guide lives on the project website, where it can be maintained, versioned, and updated independently of any single repository. This guide covers:
- DCO sign-off: All commits must include a
Signed-off-byline certifying the contributor has the right to submit the work. - Code review process: Pull requests require approval from code owners defined in
OWNERSfiles. - Coding standards: Language-specific style guides and linting requirements.
- Testing requirements: Contributors must ensure CI checks pass before requesting review.
- Community norms: Code of conduct, communication expectations, and escalation paths.
- DCO sign-off: All commits must include a
- Consistent contributor experience: By centralizing guidance, all Kubeflow sub-projects (Pipelines, Katib, Notebooks, Trainer, etc.) share the same contribution expectations, reducing confusion for contributors who work across multiple repositories.
This approach balances discoverability (GitHub surfaces CONTRIBUTING.md automatically) with maintainability (a single canonical document to update).