🏥 Repo Health Dashboard

[github-actions]

Last Updated: 2026-03-17 06:19 UTC | Status: 🟡 Warning | Run: #23181225274

---

📊 Executive Summary

Repository health at warning level. Main concerns: 217 untriaged issues and 816 issues without milestones require triage attention. P1 backlog stable at 23 issues. No critical issues detected (P0 #5805 is baselined). Core workflows stable (backport.yml & locker.yml both succeeding). AzDO monitoring unavailable (no AZDO_PAT configured).

---

🔴 Critical Findings

No critical findings detected ✅

Note: P0 issue #5805 (MKLImports PDB not included) is baselined as known tech debt since 2021.

---

🟡 Warning Findings

Status	Finding	Details	Impact
🆕 NEW	High untriaged count	217 issues labeled "untriaged"	Backlog visibility & prioritization
🆕 NEW	Issues without milestone	816 open issues have no milestone	Release planning & tracking
🆕 NEW	P1 backlog	23 P1 issues (many long-standing)	See baseline for known items

Top untriaged issues:

• [agentics] Failed runs #7594 — [agentics] Failed runs (tracking issue)
• PoC of repository ai bootstrap #7585 — PoC of repository ai bootstrap
• 🏥 Repo Health Dashboard #7584 — Repo Health Dashboard (this issue)
• Fix bug that causes Merge to fail with empty DataFrames #7573 — [Tokenizers] Add GPT-5.x model support
• DataFrame Merge method throws exception when one of the DataFrames is empty. #7572 — [Tokenizers] Add GPT-5.3 model support

---

ℹ️ Info Findings

Finding	Details
Issue Counts	P0: 1, P1: 23, P2: 298, P3: 101, bug: 58
Open PRs	~20 active pull requests
GitHub Actions	backport.yml: ✅ Success, locker.yml: ✅ Success
Issue Velocity	0 opened / 0 closed (last 24h)

---

📈 Key Metrics (7-day trends)

Metric	Current	Previous	Trend
P0 Issues	1	1	➡️ Stable
P1 Issues	23	23	➡️ Stable
P2 Issues	298	0	⬆️ Increased
P3 Issues	101	—	—
Bug Issues	58	0	⬆️ Increased
Untriaged Issues	217	69	⬆️ Significantly increased
No Milestone	816	—	—
Open PRs	~20	29	⬇️ Decreased

Note: Metric changes may reflect improved data collection rather than actual repository changes. Previous run had limited visibility into P2/P3/bug issues.

---

🔄 GitHub Actions Status

Workflow	Last Run	Status	Notes
backport.yml	2026-03-16	✅ Success	Run #3037 completed successfully
locker.yml	2026-03-16	✅ Success	Run #837 completed successfully

Both monitored GitHub Actions workflows running cleanly. No failures in recent runs.

---

🏥 Azure DevOps Pipelines

⚠️ AZDO_PAT not configured — pipeline monitoring disabled

Note: Configure AZDO_PAT secret to monitor these pipelines in dnceng/public:

• vsts-ci
• codecoverage-ci
• night-build
• outer-loop-build

---

📋 Baselined Items

Source: .github/health-baseline.md

Summary:

• 24 P1 issues — Tech debt and feature requests (2018-2023)
• 1 P0 issue — MKLImports PDB not included with packages #5805 (MKLImports PDB, known packaging issue since 2021)
• 6 PRs — Work in progress or community contributions
• Baseline last updated: 2026-03-06 (11 days ago)

Sample baselined P1 issues:

• MKLImports PDB not included with packages #5805 (P0) — MKLImports PDB not included with packages
• Legacy images need to be updated #7447 — Legacy images need to be updated
• Error: "Microsoft.ML currently supports 'x64' and 'x86' processor" when target runtime is *linux-arm* or *linux-arm64* #6588 — Error for linux-arm/arm64 processor targets
• Exposing the tree for multiclass classification #6370 — Exposing the tree for multiclass classification
• CreateEnumerable code fails in Visual Studio FSI but works in .NET Interactive notebook? #6353 — CreateEnumerable fails in VS FSI but works in notebook
• Add substitutes for 4 IntelMKL methods so SymSgd can be added to non x86/x64 builds #5798 — Add substitutes for IntelMKL methods for non-x86/x64
• Memory leak  #5744 — Memory leak
• Migrate to VSTest for all Unit Tests #5587 — Migrate to VSTest for all Unit Tests

See baseline file for complete list of 30 baselined items.

---

📝 Change Summary

Since last run (2026-03-16 06:27 UTC, ~24h ago):

Findings:

• 🆕 New: 3 warning findings (untriaged count, no milestone, P1 backlog)
• ✅ Resolved: 2 (previous untriaged & stale PR warnings)
• 📌 Existing: 0
• 📋 Baselined: 30 issues + 6 PRs from baseline file

Metrics:

• ⚠️ Concern: Untriaged issues increased 69→217 (likely improved data collection)
• ℹ️ Info: P2/P3/bug labels now tracked (298/101/58 respectively)
• ✅ Stable: Workflows healthy (100% success rate)
• ⬇️ Improved: Open PRs decreased 29→20

Key Observations:

• Significant jump in untriaged count (69→217) likely reflects broader data collection rather than new issues
• No milestone tracking reveals 816 issues lacking release planning
• P1 backlog stable at 23 issues (most are baselined as known tech debt)
• GitHub Actions workflows running cleanly
• AzDO pipeline monitoring unavailable (no PAT configured)

---

🎯 Recommendations

1. Triage Backlog: Focus on reducing untriaged count from 217 toward target of <50
2. Milestone Assignment: Begin assigning milestones to help with release planning (816 issues currently untracked)
3. P1 Review: Many P1 issues are baselined as old tech debt — consider re-evaluation or closure
4. AzDO Monitoring: Configure AZDO_PAT to enable Azure Pipelines health tracking

---

🔗 Resources

• Baseline: .github/health-baseline.md
• This Run: https://github.com/dotnet/machinelearning/actions/runs/23181225274
• Workflow: repo-health-check.lock.yml
• Untriaged Issues: https://github.com/dotnet/machinelearning/issues?q=is:issue+is:open+label:untriaged
• Issues without Milestone: https://github.com/dotnet/machinelearning/issues?q=is:issue+is:open+no:milestone

---

Dashboard generated by repo-health-check.lock.yml • Next run: ~24h

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