🏥 Repo Health Dashboard

[github-actions]

🏥 Repo Health Dashboard

Last Updated: 2026-04-20 06:42 UTC
Status: 🟡 Warning
Workflow Run: #24652141730

---

Executive Summary

Repository health remains at warning status primarily due to a large backlog of 216 untriaged issues. All monitored GitHub Actions workflows are healthy. No critical findings detected. Issue triaging and PR review assignment need attention to improve overall health.

---

🔴 Critical Findings (0)

No critical findings at this time.

---

🟡 Warning Findings (1)

Finding	Status	Details
216 untriaged issues	🆕 NEW	Large backlog of issues without proper triage — requires milestone assignment and priority labels

---

ℹ️ Info / Healthy (3)

Finding	Status	Details
10 PRs without assigned reviewers	🆕 NEW	Pull requests need review assignment to unblock progress
20 needs-info issues stale >14 days	🆕 NEW	Issues waiting for user response with no activity for over 2 weeks
4 stale PRs (>30 days inactive)	🆕 NEW	PRs need attention, refresh, or closure decision

---

📊 Repository Metrics

Issues by Priority

Priority	Count	Notes
P0	1	✅ #5805 (MKLImports PDB) — assigned to @michaelgsharp
P1	23	Including #7447 (legacy images), #6588 (ARM support), and others
P2	298	Medium priority features and enhancements
P3	101	Lower priority improvements
Bug	59	Bug reports across all priorities
Untriaged	216	⚠️ Large backlog requiring triage workflow

Pull Requests

Metric	Count	Status
Open PRs	11	Including #7605 (quantile regression), #7601 (Arcade SDK)
Without Reviewers	10	⚠️ Need review assignment
Stale (>30 days)	4	Need refresh or closure

Workflows (Last 30 runs)

Workflow	Success	Failure	Status
backport.yml	1	0	✅ Healthy (last run: Apr 19)
locker.yml	30	0	✅ Healthy (all passing)

Note: Azure DevOps pipeline monitoring disabled — AZDO_PAT not configured. Cannot monitor vsts-ci, codecoverage-ci, night-build, or outer-loop-build.

---

📈 Trend Analysis

Note: This is run #2. Previous run was on 2026-04-19 06:30 UTC.

Metric	Current	Previous	Change
Untriaged Issues	216	216	➡️ Stable
P0 Issues	1	1	➡️ Stable
P1 Issues	23	23	➡️ Stable
P2 Issues	298	298	➡️ Stable
Open PRs	11	11	➡️ Stable
Stale PRs	4	4	➡️ Stable
Workflow Health	✅	✅	✅ All passing

Trend Legend: ⬆️ Increasing | ⬇️ Decreasing | ➡️ Stable | ✅ Healthy

---

✅ Recently Resolved (0)

No findings resolved since last run.

---

🔍 Investigation Status

No new investigations dispatched — No critical findings requiring immediate investigation detected.

Investigation Budget: 0 / 5 dispatches used this run

---

🎯 Recommendations

1. Address Untriaged Backlog: Schedule batch triage sessions to process the 216 untriaged issues
2. PR Review Assignment: Assign reviewers to the 10 PRs currently without review to maintain velocity
3. Stale Issue Cleanup: Review the 20 stale needs-info issues — close if abandoned, or ping users for updates
4. Enable AzDO Monitoring: Configure AZDO_PAT secret to monitor primary CI pipelines (vsts-ci, codecoverage-ci, night-build, outer-loop-build)
5. P1 Backlog: Review and potentially promote or defer P1 items to manage the 23-item backlog

---

📚 Resources

• Baseline File: .github/health-baseline.md (not found — consider creating one to mark acceptable baseline findings)
• Previous Run Cache: /tmp/gh-aw/cache-memory/findings.json (updated this run)
• Azure Pipelines: Monitoring disabled (requires AZDO_PAT)
• Next Run: Scheduled daily

---

_{Generated by Repo Health Check — Orchestrator | Run #24652141730}

Generated by Repo Health Check — Orchestrator

[github-actions]

🔍 Investigation: I3-UNTRIAGED-BACKLOG

Finding: High untriaged backlog: 100+ issues, many > 7 days old
Severity: high
Category: issue

Evidence

1. 154 untriaged issues in first 200 open issues (77% of sample) — Source: GitHub API query, 2026-03-06

   • 147 issues explicitly labeled untriaged
   • 7 issues with no labels at all

2. Age distribution is heavily skewed old:

   • 129 issues > 365 days (84%)
   • 20 issues 91-365 days (13%)
   • 2 issues 31-90 days (1%)
   • 2 issues 8-30 days (1%)
   • 1 issue 0-7 days (1%)
   • Source: Parsed created_at timestamps from GitHub API

3. 90 unique authors across 147 untriaged issues — indicating both community and team contributions stuck in backlog — Source: User analysis of GitHub issue data

4. Top contributors to untriaged backlog:

   • ericstj (Microsoft team): 14 untriaged issues
   • superichmann: 11 untriaged issues
   • 80LevelElf: 7 untriaged issues
   • asmirnov82 (Microsoft team): 6 untriaged issues
   • 23 untriaged issues from Microsoft team members (ericstj, asmirnov82, luisquintanilla, michaelgsharp)
   • Source: GitHub user metadata analysis

5. Partial triage has occurred on 55% of untriaged issues:

   • 81/147 have additional labels beyond untriaged (55%)
   • 66/147 have ONLY untriaged label (45%)
   • Source: Label analysis from GitHub API

6. Issue type breakdown of untriaged:

   • 49 enhancements (33%)
   • 7 questions (5%)
   • 6 blocking-clean-ci (4%)
   • 6 Known Build Error (4%)
   • 1 bug (1%)
   • 0 have area/priority/kind labels (no structured triage)
   • Source: Label name pattern matching

7. Examples of very old untriaged issues:

   • ArgumentOutOfRangeException when running Microsoft.ML.Fairlearn.Tests.GridSearchTest.TestGridSearchTrialRunner2 #6842 (891 days): "ArgumentOutOfRangeException in Fairlearn tests" — blocking-clean-ci, Known Build Error, untriaged
   • Microsoft.ML.Fairlearn.Tests.GridSearchTest.TestGridSearchTrialRunner2 failed with bestResult.Metric comparison #6843 (890 days): "Microsoft.ML.Fairlearn test failure" — blocking-clean-ci, Known Build Error, untriaged
   • LightGBM Multiclassification trainer returning error code -1 "Number of classes should be specified and greater than 1 for multiclass training" but I can't see where to specify the number of classes #6844 (890 days): "LightGBM returning error" — untriaged only
   • Source: GitHub issue ArgumentOutOfRangeException when running Microsoft.ML.Fairlearn.Tests.GridSearchTest.TestGridSearchTrialRunner2 #6842, Microsoft.ML.Fairlearn.Tests.GridSearchTest.TestGridSearchTrialRunner2 failed with bestResult.Metric comparison #6843, LightGBM Multiclassification trainer returning error code -1 "Number of classes should be specified and greater than 1 for multiclass training" but I can't see where to specify the number of classes #6844 metadata

8. Recent untriaged issues (not being triaged promptly):

   • TreeEnsembleRegressor is deprecated in ONNX #7581 (17 days): "TreeEnsembleRegressor deprecated in ONNX" — legitimate bug report with repro
   • Add Melt method #7577 (25 days): "Add Melt method" — enhancement request
   • Add CountDistinct method to GroupBy #7574 (34 days): "Add CountDistinct to GroupBy" — enhancement request
   • erfInv is very inneficient #7568 (50 days): "erfInv inefficient" — perf issue with PR fix: performance of erfinv #7568 #7569 already submitted
   • Source: GitHub issue TreeEnsembleRegressor is deprecated in ONNX #7581 content + timestamp analysis

9. Some untriaged issues have milestones assigned:

   • Update build containers #7411 "Update build containers" — no labels, but assigned to ML.NET 5.0 milestone
   • Source: GitHub issue Update build containers #7411 metadata

10. Known baseline exists but doesn't address triage process:

    • Baseline covers 24 P1 issues and 6 PRs as accepted technical debt
    • No baseline for untriaged issues or triage SLA
    • Source: .github/health-baseline.md

Root Cause

Confidence: High

The untriaged backlog is a process breakdown, not a resource constraint. The evidence shows:

1. Triage process is incomplete or inconsistent: 84% of untriaged issues are > 1 year old, including issues from Microsoft team members, indicating systemic triage neglect rather than a recent spike.

2. No triage SLA or automation: Issues remain untriaged for months/years without triggering any escalation. The untriaged label is applied automatically (likely on creation) but never removed systematically.

3. Partial triage is happening but incomplete: 55% of untriaged issues have other labels (enhancement, question, blocking-ci) suggesting someone looked at them but never removed the untriaged label, indicating confusion about triage completion criteria.

4. Build/CI issues are not being prioritized: 6 issues marked both blocking-clean-ci and untriaged have sat for 800+ days, suggesting either the blocking-clean-ci label is misapplied or the triage process doesn't prioritize build health.

5. The backlog is stable/growing, not clearing: With only 1 issue untriaged in the last 7 days but 129 still sitting from >365 days ago, the backlog is not being worked down.

Recommendations

Priority	Action	Who
🔴 Immediate	Triage Sprint: Dedicate team capacity to triage top 50 oldest untriaged issues (>365 days) within 2 weeks. Remove untriaged label + add area/priority or close as duplicate/won't-fix.	@ericstj @asmirnov82 @michaelgsharp
🔴 Immediate	CI blocker audit: Investigate 6 issues labeled blocking-clean-ci + untriaged (891+ days old). Either fix/close or remove blocking-clean-ci label if not actively blocking.	@ericstj
🟡 Short-term	Define triage completion criteria: Document when untriaged label should be removed (e.g., after area + priority + assignee OR decision to close). Add to CONTRIBUTING.md.	Maintainers
🟡 Short-term	Implement triage SLA bot: Create automation to escalate issues that remain untriaged for >7 days (ping maintainers) and >30 days (label needs-maintainer-attention).	DevOps/Maintainers
🟡 Short-term	Triage rotation: Establish weekly rotation for team members to triage new issues within 7 days of creation.	@ericstj (to coordinate)
ℹ️ Long-term	Baseline triage backlog: If capacity doesn't exist to triage 129 old issues, consider adding "untriaged backlog >1 year" to health-baseline.md as accepted tech debt with 90-day re-evaluation.	Maintainers
ℹ️ Long-term	Issue templates: Add structured issue templates that pre-label issues by type (bug/enhancement/question) to reduce manual triage burden.	Maintainers

Related

• Dashboard: 🏥 Repo Health Dashboard #7584 (Repo Health Dashboard)
• Health baseline: .github/health-baseline.md (24 P1 issues baselined, but no triage process baseline)
• Sample untriaged issues:
  • ArgumentOutOfRangeException when running Microsoft.ML.Fairlearn.Tests.GridSearchTest.TestGridSearchTrialRunner2 #6842 (891 days) — CI blocker
  • TreeEnsembleRegressor is deprecated in ONNX #7581 (17 days) — Recent bug
  • Update build containers #7411 (11 days) — No labels but has milestone
• Partial triage visible in: Add Melt method #7577, Add CountDistinct method to GroupBy #7574, erfInv is very inneficient #7568 (have enhancement or other labels + untriaged)

---

Investigated by repo-health-investigate • Finding: I3-UNTRIAGED-BACKLOG

Generated by Repo Health — Investigate Finding

[github-actions]

🔍 Investigation: P5-STALE-7569

Finding: PR #7569 stale 42 days: fix performance of erfinv
Severity: high
Category: pr

Evidence

1. PR opened Jan 15, 2026 by community contributor @JeWaVe — [Source: PR fix: performance of erfinv #7568 #7569 metadata]
2. Last activity Jan 23, 2026 (42 days ago) — author asked "There was no tests before. Should I add some?" — [Source: PR comment #3789039796]
3. Zero maintainer engagement — No reviewers assigned, no maintainer comments, no reviews — [Source: PR reviews API returns empty array]
4. CI status: pending with 0 checks — No CI pipelines have run on this PR — [Source: PR status checks show "pending" with total_count: 0]
5. Related issue erfInv is very inneficient #7568 also untriaged — The linked issue is still labeled "untriaged" and has zero comments — [Source: Issue erfInv is very inneficient #7568, label: untriaged, comments: 0]
6. Valid performance improvement — Changes move coefficient computation from O(n) per call to lazy static initialization — [Source: PR diff in ProbabilityFunctions.cs]
7. Only community-contribution label — No area labels, no triage, no priority assignment — [Source: PR labels array contains only "community-contribution"]
8. Author is responsive — Author replied 8 days after opening, actively seeking guidance — [Source: Author comment on Jan 23]

Root Cause

Confidence: High

This PR has fallen into the community contribution black hole — a pattern where external contributors submit valid improvements but receive zero maintainer engagement due to triage and review process gaps. The PR is technically sound (performance optimization with lazy initialization), the author is responsive and asking for guidance, but no maintainer has:

1. Triaged the related issue (erfInv is very inneficient #7568)
2. Assigned reviewers to the PR
3. Provided feedback on the test coverage question
4. Triggered CI pipelines

The 42-day staleness is not due to author unresponsiveness or technical blockers, but rather lack of maintainer bandwidth or awareness.

Recommendations

Priority	Action	Who
🔴 Immediate	Assign a reviewer (ideally from CpuMath/performance area) to PR #7569 and triage issue #7568. Author needs guidance on test requirements.	@dotnet/ml-team
🔴 Immediate	Trigger CI pipeline manually if needed — currently shows 0 checks have run, which may indicate a fork permission issue.	DevOps/Maintainer
🟡 Short-term	Respond to author's test coverage question from Jan 23. Even if answer is "no tests needed for this path," explicit guidance prevents further staleness.	Area owner
🟡 Short-term	Apply area label (e.g., area-CpuMath) and priority label to surface PR in relevant team's backlog.	Triager
ℹ️ Long-term	Implement first-response SLA for community PRs — set expectation that all community PRs get some maintainer response within 7 days, even if just "on our radar, reviewing soon."	@dotnet/ml-team
ℹ️ Long-term	Add GitHub Actions automation to auto-assign reviewers based on file paths (e.g., CpuMath changes → assign CpuMath area owner).	DevOps

Related

• Issue erfInv is very inneficient #7568: erfInv is very inneficient — still untriaged
• Pattern: This is the author's only open PR; responsive external contributor at risk of disengagement
• Similar pattern: Search for other community-contribution PRs with no assignee/reviewer and >30 days old may reveal systemic issue

---

Investigated by repo-health-investigate • Finding: P5-STALE-7569

Generated by Repo Health — Investigate Finding

[github-actions]

📅 Daily Health Update — March 7, 2026

⚠️ Key Changes

Metric	Change	Notes
Untriaged Issues	🔴 +111 (100 → 211)	Significant spike — needs investigation
P2 Issues	↑ +198 (100 → 298)	Possible data correction or bulk relabeling
Stale PRs	→ 1 issue	PR #7569 aged to 43 days
CI Workflows	✅ All green	100% success rate maintained

🔍 Analysis

The +111 untriaged issue spike is the most significant change. Possible causes:

1. Bulk milestone removal or label changes
2. Previous count was incomplete (pagination issue)
3. Actual increase in unprocessed issues

Action needed: Manual review of untriaged issues to determine cause.

📊 Severity Status

• Critical: None
• Warning: 2 (untriaged backlog, stale PR)
• Info: 1 (high P2/P3 counts)

All findings are EXISTING (Day 1) — no new problems, no resolutions.

Generated by Repo Health Check — Orchestrator

[github-actions]

🔍 Investigation: I3-UNTRIAGED-BACKLOG-210

Finding: High untriaged backlog: 211 issues, grew +111 in 24h - investigate cause
Severity: high
Category: issue

Evidence

1. No actual spike occurred — Only 1 new issue was created between Mar 6-7 (🏥 Repo Health Dashboard #7584, the dashboard itself) — Source: GitHub Issues Search API, created:>=2026-03-06 returns 1 result

2. Current count: 224 untriaged issues (211 + dashboard) — Source: GitHub Search API label:untriaged returns total_count: 224

3. Run Get a working build #1 (Mar 6) reported "100+" issues — Used perPage:100 limit and hit pagination cap — Source: Workflow logs 22778370176

4. Run Fixed the syntax of cited example. #2 (Mar 7) counted correctly: 212 - 1 = 211 — Source: Workflow logs 22793478827 show calculation "Untriaged: 212 - 1 (dashboard) = 211 total"

5. Previous investigation (Mar 6) found 154 untriaged by processing paginated results manually — Source: Comment on 🏥 Repo Health Dashboard #7584 from investigation run 22778656021

6. Dashboard body says "100+" in multiple places — Run Get a working build #1's dashboard used "100+" notation for P2, P3, and untriaged counts, indicating awareness of pagination limits — Source: Issue 🏥 Repo Health Dashboard #7584 body from first run

7. The +111 "growth" is a measurement artifact: 211 (actual count) - 100 (truncated count) = 111 — Source: Math on reported values

Root Cause

Confidence: High

This is a false positive caused by pagination inconsistency, not an actual backlog spike.

Run #1 on March 6 used the github-list_issues tool with perPage: 100, which returns at most 100 results. The orchestrator agent likely counted the returned results and reported "100" (or rounded to "100+" for display), knowing pagination was capped but not fetching additional pages.

Run #2 on March 7 appears to have used either:

• A different counting method (GitHub Search API which returns total_count metadata), OR
• Pagination to fetch all results, OR
• A corrected query

This resulted in the accurate count of 211, creating an apparent "+111" spike that is actually just better measurement precision.

Why the inconsistency?

• The orchestrator workflow uses an AI agent to collect data, and the agent may have used different approaches on different runs
• The list_issues tool requires manual pagination (perPage max is 100), while search_issues returns total counts
• Run Get a working build #1 was the first-ever run (no previous baseline), so the agent may have used a quick sampling approach
• Run Fixed the syntax of cited example. #2 corrected the methodology after seeing the dashboard

Recommendations

Priority	Action	Who
🔴 Immediate	Update dashboard to clarify — Add note that Mar 6 count (100) was incomplete due to pagination limits. Correct the 24h delta to show "measurement correction" not "growth."	Orchestrator maintainer
🔴 Immediate	Close this investigation finding — Mark as false positive / measurement artifact. The actual triage backlog issue was already investigated separately.	This workflow
🟡 Short-term	Fix orchestrator counting — Ensure the orchestrator always uses search_issues for counts (returns total_count metadata) rather than list_issues (requires manual pagination).	Workflow author
🟡 Short-term	Standardize on pagination strategy — Document in the orchestrator workflow: for counts, always use search API; for details, use list API with pagination loop.	Workflow author
ℹ️ Long-term	Add count validation — If any metric shows >90 in first run, flag for pagination check. Add a "data quality" note if counts are capped at limits.	Workflow author

Related

• Dashboard: 🏥 Repo Health Dashboard #7584
• Previous untriaged investigation: Comment from Mar 6 — correctly found 154 issues using pagination
• Actual triage backlog: 224 untriaged issues (stable/growing slowly, not a sudden spike)
• Workflow runs:
  • Run Get a working build #1: 22778370176 — first run, capped at 100
  • Run Fixed the syntax of cited example. #2: 22793478827 — corrected count to 211

Conclusion

No action needed on the backlog itself. The 211 untriaged issues are the same issues that existed yesterday. The real triage backlog problem (129 issues >365 days old) was already investigated and has recommendations in the Mar 6 investigation comment.

This finding should be marked as RESOLVED - False Positive (Measurement Error).

---

Investigated by repo-health-investigate • Finding: I3-UNTRIAGED-BACKLOG-210

Generated by Repo Health — Investigate Finding

[github-actions]

🔍 Investigation: P5-STALE-7569

Finding: PR #7569 stale 43 days without review - performance fix for erfinv
Severity: Medium
Category: pr

---

Evidence

1. PR created: 2026-01-15 by first-time contributor @JeWaVe — Source: PR metadata
2. Associated issue: erfInv is very inneficient #7568 (untriaged) filed by same author highlighting inefficiency in ProbabilityFunctions.cs where a 1000-element array is allocated on every Erfinv() call
3. Code change: Refactors coefficient computation into lazy-loaded static readonly struct, moving allocation from O(n) per-call to O(1) lifetime — Source: PR diff
4. CI status: Pending (no checks run) — Source: commit status API
5. Review status: No reviewers assigned, no reviews submitted — [Source: PR metadata]
6. Coverage concern: Codecov reports 0% patch coverage (10 lines missing test coverage), author asked "Should I add some?" 8 days after PR creation — Source: PR comment 2026-01-23
7. No response: Zero maintainer engagement since filing (43+ days)
8. Community pattern: Recent community PRs merged within 8-45 days (median ~13 days) — [Source: GitHub search for merged community contributions since 2024-01-01]
9. Author history: No previous commits or merged PRs in this repository — [Source: git log + GitHub search]
10. Related work: Same file (ProbabilityFunctions.cs) last modified 2026-03-06 in unrelated commit — [Source: git log]

---

Root Cause

Confidence: High

This PR stalled due to lack of maintainer triage and review assignment:

1. No automated review assignment: Repository has no CODEOWNERS file, so community PRs require manual reviewer assignment
2. Limited maintainer bandwidth: Only 1 active committer since 2025-12-01 (Jan Krivanek), repository merged 23 PRs in past 4 months (avg 5.75/month)
3. Missing test coverage: While contributor offered to add tests, no maintainer guidance was provided on whether tests are needed or how to structure them
4. Untriaged associated issue: Issue erfInv is very inneficient #7568 still marked "untriaged" after 51 days, indicating broader triage backlog

The PR itself appears technically sound (simple refactoring from per-call allocation to static lazy-loaded coefficients), but fell through the cracks due to process gaps.

---

Recommendations

Priority	Action	Who
🔴 Immediate	Assign reviewer to PR #7569 — Based on recent merge activity, assign (a href="https://github.com/JanKrivanek")`@JanKrivanek`(/a) or (a href="https://github.com/tarekgh")`@tarekgh`(/a) (both merged performance-related PRs recently). Provide guidance on test requirements.	Repo maintainers
🔴 Immediate	Triage issue #7568 — Remove "untriaged" label and confirm whether performance fix is desired (original code comment admits inefficiency)	Repo maintainers
🟡 Short-term	Create CODEOWNERS file — Map src/Microsoft.ML.CpuMath/ and other core areas to specific maintainers for automatic review assignment on community PRs	Repo maintainers
🟡 Short-term	Document test requirements — Update CONTRIBUTING.md to clarify when tests are required vs. optional for performance refactorings of internal utilities	Repo maintainers
ℹ️ Long-term	Add PR staleness automation — Configure bot to ping reviewers when community PRs have no activity for 14+ days (similar to the repo-health-check workflow)	Repo maintainers

---

Related

• Issue: erfInv is very inneficient #7568 — original bug report (untriaged)
• Pattern: 10 open PRs currently (as of 2026-03-07), some with similar staleness patterns
• Precedent: Community PR Fix bug that causes Merge to fail with empty DataFrames #7573 merged in 8 days (similar scope: bug fix, test coverage added)

---

Technical Merit Assessment

The proposed change is architecturally sound:

• ✅ Eliminates repeated O(n²) computation (1000 array elements × nested loop)
• ✅ Thread-safe (CLR guarantees static constructor runs once)
• ✅ Suppresses CA2207 with explanatory comment (appropriate for perf optimization)
• ⚠️ Missing test coverage (but original code also had none)

Recommendation: This PR should be reviewed and either merged (with or without tests) or closed with clear rationale within 7 days.

---

Investigated by repo-health-investigate • Finding: P5-STALE-7569 • Date: 2026-03-07

Generated by Repo Health — Investigate Finding

[github-actions]

📅 Daily Update — 2026-03-08

Summary

Repository health: 🟡 Warning (no critical issues)

Changes Since Last Run

• ⚠️ Untriaged backlog grew: 100+ → 212 issues (4× threshold)
• ✅ Stale PRs improved: 7 total → 7 total (but only 1 non-baselined)
• ✅ Workflows stable: No failures in backport.yml or locker.yml

Current Snapshot

Metric	Count	Status
P0 Issues	1	✅ Baselined
P1 Issues	23	→ Stable
Untriaged	212	⚠️ Needs attention
Open PRs	14	✅ Healthy
Stale PRs	1 (+ 6 baselined)	✅ Improved

Recommendations

1. High Priority: Triage the 212 untriaged issues — this is 4× the acceptable threshold of 50
2. Monitor P1 issues to ensure critical bugs have owners
3. Continue current PR review pace

---

View full details in the dashboard body above.

Generated by Repo Health Check — Orchestrator