Principle:Kubeflow Kubeflow Feature Development Tracking
| Knowledge Sources | |
|---|---|
| Domains | Release Management, Feature Tracking, Working Group Coordination |
| Last Updated | 2026-02-13 00:00 GMT |
Overview
Feature Development Tracking is the practice of monitoring and coordinating feature progress across multiple independent Working Groups using GitHub issues, theme-based grouping, and centralized release board visibility.
Description
Kubeflow's distributed architecture means that features are developed independently across sub-project repositories by their respective Working Groups. Feature Development Tracking provides the coordination mechanism that ensures all planned features are progressing toward the release deadline and that cross-cutting concerns are identified early.
Each Working Group maintains its own tracking issue in its sub-project repository (e.g., Template:Code for Trainer). These tracking issues serve as the source of truth for what that WG plans to deliver in a given release. Features are grouped into themes (e.g., "Trainer V2.0", "Model Registry new features") that communicate the high-level narrative of the release to the community.
The ROADMAP.md file in the main kubeflow/kubeflow repository serves as the centralized record, listing all themes and linking to per-WG tracking issues for each release. This dual-layer approach (centralized themes in ROADMAP.md, detailed tracking in per-WG issues) balances the need for overall visibility with Working Group autonomy.
Usage
Feature Development Tracking should be used:
- Throughout the active development phase of a release cycle
- When Working Groups need to report progress to the release team
- When the release team needs to assess readiness for feature freeze
- When identifying features at risk of missing the release deadline
- When communicating the release narrative to the broader community
Theoretical Basis
The tracking process operates at multiple levels:
Level 1: Theme-Based Grouping
Features are organized into high-level themes that communicate the release's strategic direction. Themes emerge from community priorities and Working Group roadmaps during the planning phase. For example, the v1.11 release themes include:
- Trainer V2.0
- Model Registry new features
- KServe improvements
- Pipelines enhancements
- Katib updates
- Spark Operator features
Level 2: Per-WG Tracking Issues
Each Working Group creates a tracking issue in its own repository. This issue lists all features, bug fixes, and enhancements planned for the release. The tracking issue serves as:
- A checklist of deliverables the WG has committed to
- A discussion thread for WG-internal coordination
- A reference point for the release team to check progress
- A historical record of what was planned versus delivered
Level 3: GitHub Project Board Integration
Per-WG tracking issues are linked to the central GitHub Project Board for the release. This provides the release team with a single dashboard view of progress across all Working Groups without requiring them to visit each sub-project repository individually.
Level 4: Per-Component Version Targeting
Each sub-project targets a specific version for its contribution to the platform release. For example, in the v1.11 release:
- KServe targets v0.15.2
- Katib targets v0.19.0
- Pipelines targets 2.15.0
- Model Registry targets v0.3.4
- Spark Operator targets v2.4.0
Progress Assessment Framework
The release team periodically reviews tracking issues to assess:
- On track: Feature development proceeding as planned
- At risk: Feature may not make the deadline; needs attention
- Deferred: Feature explicitly moved to the next release
- Completed: Feature merged and verified
This multi-level approach provides both the high-level narrative needed for community communication and the detailed tracking needed for release management.