konveyor-labels-summary.md

Konveyor GitHub Label Audit Summary

Audit Date: January 28, 2026 Organization: konveyor

---

Executive Summary

This audit analyzed GitHub labels across the Konveyor organization to identify inconsistencies, redundancies, and opportunities for standardization. The findings reveal significant label fragmentation that can be addressed through a structured consolidation strategy based on open source best practices.

Key Metrics

Metric	Value
Total Repositories Audited	64 active (27 archived skipped)
Total Labels Across All Repos	4,186
Unique Labels	219
Labels with Color Variations	37
Labels Used in Only One Repo	83
Proposed Standardized Labels	67
Reduction Potential	69.4%

---

Key Findings

1. Most Common Labels

Three labels are present in all 64 repositories, indicating strong baseline consistency:

Label	Repositories	Notes
documentation	64	GitHub default
good first issue	64	GitHub default, used by CLOTributor
help wanted	64	GitHub default, used by CLOTributor

The next tier of widely-used labels (53 repos) follows Kubernetes-style naming conventions:

• kind/bug, kind/feature, kind/documentation
• priority/critical-urgent, priority/important-soon, priority/backlog
• triage/duplicate, triage/needs-information, triage/not-reproducible
• lgtm, size/S, size/M, size/L

This suggests a common label template was applied to major repositories, which is a positive pattern to extend organization-wide.

2. Label Fragmentation Areas

Color Inconsistencies: 37 labels have different colors across repositories. Examples:

• help wanted: Uses both #006b75 and #008672
• size/L: Uses both #006B75 and #ee9900
• size/M: Uses both #006B75 and #eebb00

Duplicate Concepts: Multiple labels represent the same concept:

• Bug: bug, kind/bug, fix
• Feature: enhancement, kind/feature, feat, RFE
• Documentation: documentation, kind/documentation, docs
• Technical debt: chore, Tech debt, technical debt, tech-debt

Orphaned Labels: 83 labels (38%) are used in only one repository, suggesting either:

• Overly specific labels that should be generalized
• Abandoned experiments that should be cleaned up
• Legitimate repo-specific needs (minority)

3. Notable Variations

Category	Issue	Impact
Priority labels	Multiple scales (critical/high/urgent vs critical-urgent)	Confusing prioritization
Merge blockers	do-not-merge, do not merge, WIP all in use	Inconsistent automation
Triage states	Mix of prefixed and unprefixed (wontfix vs triage/wontfix)	Filtering difficulties
Version labels	Sprint/version-specific labels (sprint 1, 0.3.0, v3 blocker)	Should use milestones

---

Top Recommendations

1. Adopt Kubernetes-Style Prefix Naming (High Priority)

Konveyor already uses Kubernetes-style labels in 53 repositories. Standardize on this convention organization-wide:

kind/        - Issue type (bug, feature, documentation, cleanup)
priority/    - Urgency level (critical-urgent, important-soon, backlog)
triage/      - Resolution status (accepted, needs-information, duplicate)
lifecycle/   - Issue age/status (stale, rotten, frozen)
size/        - Effort estimate (XS, S, M, L, XL, XXL)
area/        - Component focus (ci, testing, dependency)
do-not-merge/ - PR blockers (hold, work-in-progress)

Rationale: Prefixes simulate folder hierarchy in GitHub's flat label system, making labels easier to discover, filter, and understand.

2. Consolidate Duplicate Labels (High Priority)

Rename overlapping labels to canonical forms:

Current Labels	Consolidate To
bug, fix	kind/bug
enhancement, feat, RFE	kind/feature
documentation, docs	kind/documentation
chore, Tech debt, tech-debt	kind/cleanup
duplicate	triage/duplicate
question	triage/support
WIP, do not merge	do-not-merge/work-in-progress

3. Standardize Colors by Category (Medium Priority)

Apply consistent colors across all repositories:

Category	Color	Hex
Bug/Breaking	Red	#e11d21
Feature/Docs	Light Blue	#c7def8
Priority Critical	Red	#e11d21
Priority Important	Orange	#eb6420
Priority Backlog	Yellow	#fbca04
Triage Accepted	Green	#8fc951
Triage Other	Purple	#d455d0
Size (gradient)	Green to Red	XS:#009900 to XXL:#ee0000
Do Not Merge	Red	#e11d21
Lifecycle	Gray	#ededed
Area	Teal	#006b75

4. Add Lifecycle Labels for Automation (Medium Priority)

Create new labels to enable stale issue automation:

• lifecycle/stale - No activity for 60+ days
• lifecycle/rotten - No activity for 90+ days, candidate for closing
• lifecycle/frozen - Intentionally on hold, skip stale automation

5. Implement Label Sync Automation (Medium Priority)

Deploy a GitHub Action to sync labels across all repositories:

• Maintains consistency as labels are added/modified
• Similar to Kubernetes label_sync tool running as daily CronJob
• Define canonical labels in a YAML file in the .github repository

6. Use Milestones Instead of Version Labels (Low Priority)

Delete version-specific labels and use GitHub Milestones:

• Remove: 0.3.0, 0.3-alpha-0 blocker, sprint 1, v3 blocker
• Use: Milestones for release/sprint tracking

7. Groom Good First Issues (Medium Priority)

As a CNCF project, ensure good first issue labeled issues include:

• Clear problem description
• Acceptance criteria
• Links to development/contributing docs
• Approximate skill level or technologies involved

---

Migration Plan

The consolidation strategy proposes a 5-phase migration:

Phase	Action	Risk Level
1	Standardize colors for existing labels	Low
2	Create missing labels (lifecycle/, area/)	Low
3	Rename labels to canonical forms	Medium
4	Delete deprecated/orphaned labels	Medium
5	Deploy label sync automation	Low

Migration Statistics

Category	Count
Labels to Create	9
Labels to Rename	38
Labels to Delete	86
Labels to Keep Unchanged	57

---

Research Sources

This consolidation strategy was informed by best practices from these authoritative sources:

1. GitHub Official Documentation - Label management fundamentals and organization defaults

2. Kubernetes Label Sync System - Prefix naming conventions, automation-driven labels, daily sync approach

3. VS Code Repository Labels - Hierarchical naming for large projects, special prefix characters for automation

4. CNCF Contributors Guide - Standard labels for new contributor discovery (good first issue, help wanted)

5. Creative Commons Labels - Color schemes by category, mandatory vs optional labels

6. Dosu - Open Source Labeling Best Practices - Core vs supplemental categories, prefix hierarchy

7. Sane GitHub Labels - Status/Type/Priority framework, exclusive label application

8. GitHub - Encouraging Helpful Contributions - Using labels to attract contributors

---

Next Steps

1. Review consolidation strategy - Stakeholders should review konveyor-labels-consolidation-strategy.json for detailed migration mappings

2. Approve organization defaults - Org owners configure default labels at Repository Defaults Settings

3. Create label sync workflow - Build a GitHub Action in the .github repository to sync labels

4. Execute migration phases - Follow the 5-phase migration plan, starting with low-risk color standardization

5. Monitor and iterate - Track adoption and adjust the label schema based on feedback

---

Detailed Data Files

This summary is derived from the following audit artifacts:

File	Description
konveyor-labels-inventory.json	Complete label inventory with usage statistics
konveyor-labels-best-practices.json	Research findings from authoritative sources
konveyor-labels-consolidation-strategy.json	Detailed consolidation plan with migration mappings
konveyor-repos.json	List of all repositories in the organization
konveyor-repo-labels.json	Raw label data collected from each repository

---

Report generated as part of the Konveyor GitHub Label Audit project.