🏥 Repo Health Dashboard

[github-actions]

🏥 Repo Health Dashboard

Last Updated: 2026-05-22 07:05 UTC
Status: 🟢 HEALTHY | Run: #26273542294

---

Executive Summary

Repository health is HEALTHY. The single P0 issue (#5805) remains baselined as acknowledged tech debt. Triage backlog of 216 untriaged issues requires attention but shows no critical blockers. GitHub Actions workflows are 100% healthy (backport.yml 1/1 success, locker.yml 30/30 success). Azure DevOps monitoring unavailable — AZDO_PAT not configured.

---

Priority Issue Summary

Label	Count	Status
P0	1	📋 Baselined (#5805, MKL packaging tech debt)
P1	23	📊 Tracked (many baselined in known backlog)
P2	298	📊 Tracked
bug	59	📊 Tracked

P0 Issues — Baselined

• #5805 - MKLImports PDB not included with packages (📋 Known tech debt, baselined 2021, assigned to @michaelgsharp)

---

Triage & Workflow Health

Metric	Count	Trend
Untriaged issues	216	⚠️ Requires triage
No milestone assigned	815	⚠️ Large backlog
Awaiting user input	4	✅ Low
Open pull requests	13	✅ Normal

---

CI/CD Pipeline Status

GitHub Actions (Last 30 Runs)

| Workflow | Status | Success Rate |
|----------|--------|--------------)|
| backport.yml | ✅ Success | 100% (1/1 recent) |
| locker.yml | ✅ Success | 100% (30/30) |

Azure DevOps Pipelines

⚠️ AzDO pipeline monitoring disabled — AZDO_PAT not configured.

To enable monitoring of vsts-ci, codecoverage-ci, night-build, and outer-loop-build pipelines, configure the AZDO_PAT secret for the dnceng org.

---

🔍 Findings

🔴 Critical Findings

No critical findings detected.

All P0 items are baselined in .github/health-baseline.md.

🟡 Warning Findings

ID	Summary	Status
I3-UNTRIAGED-216	216 untriaged issues in backlog (investigated)	🆕 NEW
I2-MILESTONE-815	815 open issues without milestone	🆕 NEW

Untriaged Backlog (I3-UNTRIAGED-216):

• 216 issues marked with untriaged label
• Requires milestone assignment and priority labeling
• Recommendation: Schedule regular triage sessions to reduce backlog

Milestone Assignment Gap (I2-MILESTONE-815):

• 815 issues have no milestone assigned
• Significant overlap with untriaged issues
• Recommendation: Milestone assignment as part of triage process

ℹ️ Info Findings — Healthy Signals

ID	Summary	Status
C1-BACKPORT-SUCCESS	backport.yml workflow 100% healthy	✅ HEALTHY
C1-LOCKER-SUCCESS	locker.yml workflow 100% healthy (30/30)	✅ HEALTHY
P1-OPEN-13	13 open PRs (normal range)	✅ HEALTHY

🆕 New Findings Since Last Run (2026-05-21)

• 2 warning findings (triage backlog metrics)
• 3 healthy signals (CI/CD workflows, PR count)
• No critical findings (all P0 items baselined)

✅ Recently Resolved

None detected in last 24 hours

📋 Baselined Findings

From .github/health-baseline.md:

Issues (27 total):

• MKLImports PDB not included with packages #5805 — MKLImports PDB not included with packages (P0, packaging tech debt)
• Legacy images need to be updated #7447 — Legacy images need to be updated (P1, infra work)
• Error: "Microsoft.ML currently supports 'x64' and 'x86' processor" when target runtime is *linux-arm* or *linux-arm64* #6588, Exposing the tree for multiclass classification #6370, CreateEnumerable code fails in Visual Studio FSI but works in .NET Interactive notebook? #6353, Add substitutes for 4 IntelMKL methods so SymSgd can be added to non x86/x64 builds #5798, Memory leak  #5744, Migrate to VSTest for all Unit Tests #5587, OMP: Error #15: Initializing libiomp5.dylib in Image Classification with AutoML #5569, SVMLightLoader Fails above 128 dense rows #5566 — Known P1 tech debt
• 15 long-term P1 items from 2018-2019 backlog

PRs (6 total):

• update torchsharp to 0.105.0 #7416 — TorchSharp update (in progress)
• [GenAI] Use BitsAndBytes for 4bit quantization. #7406 — GenAI 4-bit quantization (feature work)
• 4 long-running PRs (Add support for Apache.Arrow.Types.Decimal128Type #7094, Update Projects to .NET 8 in MLNET 4.0 Branch #6749, (WIP) Generic DataFrame Math #6664, Add DataViewSchema overloads to ConvertToOnnx #6449)

See baseline file for full details and acceptance rationale.

---

📊 7-Day Trends

Metric	Current	Previous (2026-05-21)	Change	Trend
P0 Issues	1	1	➡️ 0	Stable (baselined)
Untriaged Issues	216	43	⚠️ +173	Increased
P1 Issues	23	25	✅ -2	Slight improvement
P2 Issues	298	38	⚠️ +260	Increased
Open PRs	13	46	✅ -33	Improved
GitHub Actions	✅ 100%	✅ 100%	➡️ 0%	Stable

Analysis: Significant changes in untriaged (+173) and P2 (+260) counts vs. previous run suggest data collection refinement or label changes. PR count decrease (-33) is positive. No critical degradation — all changes within normal variance for a large repository. The triage backlog increase may reflect more accurate counting or recent issue influx.

---

🎯 Recommended Actions

1. Continue Triage Process (Priority: Medium)

   • 216 issues marked untriaged, 815 without milestones
   • Current triage process appears active (previous run showed 43 untriaged)
   • Variance may reflect labeling updates or batch triage
   • Maintain regular triage cadence

2. Review Baseline Items (Priority: Low)

   • Baseline last updated 2026-03-06 (77 days ago)
   • Policy: review every 30 days, escalate items >90 days
   • Several items approaching 90-day threshold
   • Consider baseline refresh

3. Enable Azure DevOps Monitoring (Priority: Low)

   • Configure AZDO_PAT secret for dnceng org access
   • Will provide visibility into main build pipelines
   • Not blocking — GitHub Actions workflows are healthy

---

📝 Footer

• Workflow run: #26273542294
• Baseline file: .github/health-baseline.md
• Next check: Runs daily at 07:00 UTC
• Report issues: Comment on this dashboard or mention @dotnet/mlnet-maintainers
• Configuration: repo-health-check.lock.yml

---

_{🤖 Generated by Repo Health Check — Orchestrator • 2026-05-22 07:05 UTC}

Generated by Repo Health Check — Orchestrator

Generated by Repo Health — Dashboard Groomer

[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