Principle:Kubeflow Kubeflow Development And Testing
| Knowledge Sources | |
|---|---|
| Domains | Development Workflow, Issue Management, Automation, Testing |
| Last Updated | 2026-02-13 00:00 GMT |
Overview
Development and testing is the phase of the contribution workflow where contributors implement code changes in their forked repository while automated bots manage issue classification and lifecycle to keep the project's issue tracker healthy.
Description
The development and testing principle in the Kubeflow project encompasses two complementary aspects: the contributor's local development workflow (forking, branching, coding, testing) and the automated tooling that manages issue lifecycle and classification at the repository level.
On the automation side, Kubeflow employs two key bots:
- Issue Label Bot (powered by mlbot.net): Automatically classifies newly created issues by analyzing their content and applying standardized labels. The bot maps natural-language issue types to Kubeflow's label taxonomy (e.g., mapping "bug" to
kind/bug, "feature_request" tokind/feature, and "question" tokind/question). This ensures consistent labeling without requiring manual triage for initial classification.
- Stale Bot (powered by Probot Stale): Manages the lifecycle of inactive issues and pull requests. Issues that have not received activity for 90 days are marked with the
lifecycle/stalelabel and a comment notifying participants. If no further activity occurs within 7 days, the issue is automatically closed. Critical issues (those withlifecycle/frozenor priority labelsp0throughp3) are exempt from stale management, as are issues associated with milestones or projects.
Together, these automation tools reduce maintainer burden, enforce consistent workflows, and keep the issue tracker focused on active work. Contributors benefit because well-labeled issues are easier to discover and prioritize, and stale issue cleanup prevents the tracker from becoming overwhelming.
Usage
Apply development and testing automation when:
- New issues are filed and need consistent label classification without manual triage.
- The issue tracker accumulates inactive issues that need lifecycle management.
- Contributors are searching for issues to work on and need reliable label-based filtering.
- Maintainers want to ensure high-priority issues are never automatically closed.
- The project needs to balance openness (keeping issues around for context) with cleanliness (closing truly abandoned discussions).
Theoretical Basis
The development and testing automation follows a dual-loop system:
Issue Classification Loop
- Issue creation: A contributor or user files a new issue in the repository.
- Content analysis: The mlbot.net label bot analyzes the issue title and body using machine learning to determine its type.
- Label mapping: The bot applies the configured label aliases:
bugmaps tokind/bug,feature_requestandfeaturemap tokind/feature, andquestionmaps tokind/question. - Consistent taxonomy: The mapped labels follow Kubeflow's standardized
kind/*prefix convention, enabling cross-repository consistency.
Issue Lifecycle Loop
- Inactivity detection: The stale bot scans all open issues and pull requests daily to identify those without activity for 90 days (
daysUntilStale: 90). - Stale marking: Qualifying issues receive the
lifecycle/stalelabel and a notification comment explaining the policy and timeline. - Grace period: A 7-day window (
daysUntilClose: 7) allows participants to respond, re-engage, or explicitly freeze the issue. - Automatic closure: Issues that remain inactive through the grace period are automatically closed. No closing comment is posted (
closeComment: false). - Exemption rules: Issues with
lifecycle/frozen,priority/p0throughpriority/p3, associated projects, or milestones are exempt from the entire stale lifecycle.
The exemption mechanism is critical: it prevents the stale bot from closing issues that represent ongoing priorities or planned work, even if they temporarily lack visible activity.