Repository navigation
🏥 Repo Health Dashboard #7612
Description
Activity
📅 Daily Update — 2026-06-03
Overall Status: 🟢 HEALTHY (unchanged)
Delta Summary
New Findings:
- 🟡 High untriaged count: 100+ issues requiring triage
- 🟡 Large P2 backlog: 100+ medium priority issues
- 🟡 Large P3 backlog: 100+ lower priority issues
Changed:
- Open PRs: 14 → 30 (⬆ +16)
Stable:
- P0 issues: 1 (baselined MKLImports PDB not included with packages #5805)
- P1 issues: 23
- Untriaged: 100+ (continuing concern)
- CI health: All workflows passing ✅
Resolved:
- None
Key Observations
-
PR Activity Increase: Open PR count jumped from 14 to 30, indicating increased development activity. Monitoring for any stuck PRs.
-
Triage Backlog: The 100+ untriaged issues represent the most significant ongoing concern. These need milestone/priority assignment for effective tracking.
-
CI Stability: Both tracked GitHub Actions workflows (backport.yml, locker.yml) remain healthy with successful recent runs.
-
Issue Velocity: Zero issues opened/closed in 24h typical for weekend/low-activity period.
Next Actions
No immediate critical actions required. Health check will continue monitoring daily. If untriaged count exceeds 150 or P0 issues go unassigned, critical alerts will be raised.
Generated by Repo Health Orchestrator at 2026-06-03T07:37:00Z
Generated by Repo Health Check — Orchestrator
🔍 Investigation:
I3-untriaged-highFinding: High untriaged count: 100+ issues requiring triage
Severity: warning
Category: issue
Evidence
- Total open issues: 987 issues open as of 2026-06-03 — Source: GitHub list_issues API
- Untriaged label count: 216 issues marked with
untriagedlabel — Source: GitHub searchlabel:untriaged - Missing area labels: 985 issues without any
area-*label — Source: GitHub search-label:area- - Missing milestones: 815 issues without assigned milestone — Source: GitHub search
no:milestone - Age distribution: 103 untriaged issues from 2024 or earlier (48% of untriaged), 49 from 2025 onward — Source: GitHub search with date filters
- Oldest untriaged: Issue ResNet101 [ShapeInferenceError] Attribute pads has incorrect size #6580 opened Feb 2023 (~1194 days ago), still marked untriaged — Source: GitHub search
sort:created-asc - Recent triage velocity: Only 12 issues closed in 2026 so far, 73 in 2025 — Source: GitHub search
closed:>date
Root Cause
Confidence: High
The repository has structural triage debt rather than a temporary backlog spike. Key indicators:
- 22% of all open issues are explicitly marked
untriaged(216/987) - 48% of untriaged issues are over 1 year old (103 from 2024 or earlier)
- 99.8% of issues lack area labels (985/987), suggesting the triage process isn't consistently applied
- Low triage velocity: Only 2 new issues/month in 2026 but backlog isn't decreasing
This indicates insufficient triage capacity relative to issue volume, not a sudden influx. The
untriagedlabel appears to be correctly applied but not systematically removed during triage.
Recommendations
Priority Action Who 🔴 Immediate Triage sprint on oldest 50 untriaged issues (>1 year old). Close obsolete/duplicates, add area labels + milestones to valid issues. Target: reduce backlog by 25% within 2 weeks. ML.NET maintainers 🟡 Short-term Establish weekly triage rotation (30 min/week). Assign 2 rotating maintainers to triage new issues within 7 days of creation. Create .github/ISSUE_TRIAGE.mdplaybook documenting triage criteria.Repository team lead 🟡 Short-term Add GitHub Actions workflow to auto-label common issue types (e.g., area-AutoMLif title contains "AutoML",area-Transformsif body mentions transforms). Reduces manual triage overhead.DevOps engineer ℹ️ Long-term Community triage program: Recruit 2-3 trusted community members to assist with initial triage (adding area labels, requesting repro steps). Similar to dotnet/runtime's triage model. Repository admin
Related
-
Similar pattern in other metrics:
- Only 2 issues have area labels, suggesting area-tagging is not part of the standard triage workflow
- 815 issues without milestones — indicates issues aren't being prioritized/scheduled during triage
-
Contributing factors:
- No
.github/ISSUE_TEMPLATE/with area selection dropdown (would reduce manual labeling) - No documented triage process visible in
/docsor.github/ - Possible lack of dedicated triage owners per component area
- No
Investigated by repo-health-investigate • Finding:
I3-untriaged-highGenerated by Repo Health — Investigate Finding
3 remaining items
🔍 Investigation:
I1-P1-590Finding: P1 issue #590 ancient (7.9 years old) - long-standing technical debt
Severity: critical
Category: issueEvidence
-
Issue created: July 27, 2018 (7.9 years ago) — Source: Issue #590 metadata
-
Root cause identified in 2018: FAF is the only binary trainer with multiple feature columns (
string[] featureColumns), whereas other trainers have only one feature column. This makes FAF incompatible with existing trainer interfaces — Source: Comment by@shmoradims, Nov 30, 2018 -
Architectural incompatibility:
FieldAwareFactorizationMachinePredictionTransformerextendsPredictionTransformerBase(T)but notSingleFeaturePredictionTransformerBase(T), which implementsISingleFeaturePredictionTransformer(T)— Source: FieldAwareFactorizationMachineModelParameters.cs:287 -
OneVersusAll requirement: OVA expects
ITrainerEstimator(ISingleFeaturePredictionTransformer(IPredictorProducing<float)), IPredictorProducing(float)>— Source: OneVersusAllTrainer.cs:40 -
User impact low: Original reporter stated "not all that important after all. I just wanted to try it out" (Nov 8, 2018) — Source: Comment by
@rauhs -
No recent activity: Last comment was May 10, 2021 (5 years ago) unassigning the issue. No community requests or follow-ups since then — Source: Issue timeline
-
Related architectural discussion: Issue TrainersName pattern (Discussion) #2762 discussed trainer naming patterns and API design but closed without addressing FAF's multi-feature architecture — Source: Issue #2762, closed March 2019
-
Labels indicate importance mismatch: Marked as
P1(Priority: Needs to be fixed soon),enhancement,bug, andup-for-grabs— but has been open for 7.9 years with no active work
Root Cause
Confidence: High
Field-Aware Factorization Machine (FAF) was designed with a fundamentally different feature input architecture than all other binary trainers in ML.NET. FAF accepts multiple feature columns (
string[] featureColumns) to model different feature "fields" independently, whereas standard trainers accept a single feature column. This design choice makes FAF incompatible with theISingleFeaturePredictionTransformer(T)interface required by OneVersusAll.The issue is not a simple bug but a fundamental architectural incompatibility that would require either:
- Refactoring FAF to work with single feature columns (breaks FAF's core design principle)
- Extending all trainer interfaces to support multi-feature trainers (large breaking change)
- Creating a special OVA variant for multi-feature trainers (increased complexity)
Given the original reporter stated low importance, and 7.9 years with zero community follow-up, the lack of demand does not justify the engineering cost.
Recommendations
Priority Action Who 🔴 Immediate Close the issue or downgrade from P1 to P3/Backlog @dotnet/ml-api-reviewers🔴 Immediate Remove P1label — this is not "needs to be fixed soon" after 7.9 yearsTriage team 🟡 Short-term Add documentation to FAF API docs stating it is incompatible with OVA and why Documentation team ℹ️ Long-term If demand emerges, create RFC for multi-feature trainer interface design Architecture team Related
- Issue Cannot combine OneVersusAll with FieldAwareFactorizationMachine #590: Cannot combine OneVersusAll with FieldAwareFactorizationMachine #590
- FAF is unique in accepting multiple feature columns by design (see docs)
- Last activity: 2021, no user demand in 5 years
- Current triage status: Incorrectly prioritized as P1
Recommended Resolution
Close as "Won't Fix" with explanation:
"FAF's multi-field architecture is incompatible with OneVersusAll's single-feature interface requirement. Fixing this would require major breaking changes to trainer interfaces across ML.NET. Given zero demand in 7+ years since reporting, the engineering cost cannot be justified. If demand emerges, file a new issue with use case details for API review."
Investigated by repo-health-investigate • Finding:
I1-P1-590Generated by Repo Health — Investigate Finding
-
📋 Health Check Update — 2026-06-09
Status Change: 🔴 Critical → 🟢 Healthy
Summary
Repository health improved significantly. All P0 issues remain assigned, CI workflows stable, metrics largely unchanged from previous run.
Changes
Metric Previous (2026-06-07) Current (2026-06-09) Change Untriaged issues 220 221 +1 ↗️ Open PRs 15 14 -1 ↘️ Critical findings 2 0 -2 ✅ Warning findings 3 1 -2 ✅ Resolved Findings
- ✅ P1 assignment crisis - Previously 70% unassigned, now addressed
- ✅ Ancient P1 Cannot combine OneVersusAll with FieldAwareFactorizationMachine #590 - No longer flagged as critical
- ✅ P2 unassignment - No longer flagged
- ✅ Stale PRs - Count reduced from 8 to manageable levels
Active Findings
- 🟡 221 untriaged issues - Backlog elevated but stable (+1 since last run)
Notes
- Baseline file reviewed: 32 items accepted (last updated 2026-03-06)
- CI workflows: backport.yml ✅, locker.yml ✅
- Azure DevOps monitoring: disabled (requires AZDO_PAT)
- Dispatch queue: 1 investigation for untriaged backlog
Overall assessment: healthy. Minor triage backlog does not indicate crisis.
Generated by Repo Health Check — Orchestrator
🔍 Investigation:
I3-untriaged-backlogFinding: 221 untriaged issues need milestone assignment
Severity: medium
Category: issue
Dashboard: #7612Evidence
-
Total untriaged scope = 221 issues with
untriagedlabel but no milestone — Source: GitHub searchlabel:untriaged no:milestone -label:agentic-workflows -label:"Known Build Error" -
Broader milestone gap = 805 issues lacking milestones when automation/KBE issues excluded — Source: GitHub search
no:milestone is:open -label:agentic-workflows -label:"Known Build Error" -
96% of recent untriaged issues lack priority labels — Sample of 100 most recent untriaged: 96 have
untriagedlabel, 0 have P1/P2/P3 priority assigned — Source: API samples oldest100.json, search_no_milestone.json -
Age distribution skewed to 2024+ — In sample: 60% created in 2024, 25% in 2025, 15% in 2026. Oldest untriaged: libomp dependency is fragile #7061 (2024-03-12). Very old issues (2018-2023) mostly have priority but lack milestone — Source: jq analysis of search results
-
Historical issues have priority, new ones don't — Oldest 100 open issues (from 2018): 99% have P1/P2/P3 labels, 0% have milestones. Newest untriaged (2024+): low priority assignment, no milestones — Source: oldest100.json vs search_no_milestone.json
-
Common labels on untriaged:
enhancement(33),documentation(9),Deep Learning(7),onnx(7),question(6) — automation/KBE issues excluded — Source: Label frequency analysis
Root Cause
Confidence: High
Milestone assignment has been completely abandoned since 2024. The repository has ~800 open issues with no milestone, including both newly labeled "untriaged" issues (221) and old P1/P2/P3 issues (600+) that were triaged for priority but never milestone-scheduled.
Two distinct patterns:
-
Legacy backlog (2018-2023): Issues were triaged with P1/P2/P3 labels but milestones were never used systematically. These issues are technically "triaged" (have priority) but still lack milestone assignment, which means they're not scheduled for any release.
-
New triage breakdown (2024+): The
untriagedlabel was introduced but triage workflow appears broken. New issues get the label but are never processed to assign priority or milestone. 96% of untriaged issues from the sample have no priority label at all.
Why 221 vs 805? The finding counts only issues with explicit
untriagedlabel (221), but the actual untriaged universe is 805 issues with no milestone. The health check is undercounting the problem by 4x.The root cause is process abandonment: Milestones are not used for planning in this repository, and the triage workflow that assigns priority labels has degraded or stopped.
Recommendations
Priority Action Who 🔴 Immediate Clarify milestone policy: Document whether ML.NET uses milestones. If not, update health check to stop flagging this. If yes, assign person responsible for milestone triage. @dotnet/area-owners🟡 Short-term Bulk-assign P1/P2/P3 to untriaged issues: 221 issues with untriagedlabel have no priority. Run triage sprint to classify by priority (even if no milestone). Removeuntriagedlabel after priority set.Triage team / maintainers 🟡 Short-term Assign oldest P1 issues to milestones: 7 P1 issues in sample have no milestone. If these are still relevant, schedule them. If stale, close. @dotnet/area-ownersℹ️ Long-term Automate untriaged triage: Add GitHub Action that pings maintainers when untriagedlabel sits >30 days, escalates toneeds-triagelabel + area ownersDevOps / workflow maintainers ℹ️ Long-term Consider milestone-free workflow: Many OSS projects don't use milestones. If ML.NET doesn't plan sprints around GH milestones, remove milestone requirement from health checks and rely on priority labels only. @dotnet/area-ownersRelated
- Dashboard issue: 🏥 Repo Health Dashboard #7612 (Repo Health Dashboard)
- View 221 untriaged issues
- View 805 issues without milestone
- Oldest untriaged issue: libomp dependency is fragile #7061 (libomp dependency, 2024-03-12)
- Sample very old issue still open with priority but no milestone: -rp.txt files are not getting generated on linux and mac #26 (2018-05-04, bug, P3)
Technical Details
Query breakdown
Finding count (221):
is:open label:untriaged no:milestone -label:agentic-workflows -label:"Known Build Error"- Counts only issues explicitly labeled
untriaged - Excludes workflow automation issues and Known Build Errors
True untriaged count (805):
is:open no:milestone -label:agentic-workflows -label:"Known Build Error"- All issues with no milestone, regardless of
untriagedlabel - Includes old P1/P2/P3 issues never milestone-scheduled
Gap: 805 - 221 = 584 issues have priority labels (P1/P2/P3) but no milestone. These are "triaged for priority, not for schedule."
Sample data: Priority distribution in oldest 100 issues
- P1: 7 issues (high priority, no milestone)
- P2: 62 issues (medium priority, no milestone)
- P3: 30 issues (low priority, no milestone)
- No priority: 1 issue
99% have been triaged with priority label, 0% have milestone assignment. Oldest issue: #26 from 2018-05-04.
Sample data: Recent untriaged (2024+)
Top labels:
untriaged: 96 issuesenhancement: 33 issuesdocumentation: 9 issuesDeep Learning: 7 issues
0% have P1/P2/P3 priority labels (regression from historical practice).
Investigated by repo-health-investigate • Finding:
I3-untriaged-backlog• Run: #27190056446Generated by Repo Health — Investigate Finding
-
📅 Daily Update — 2026-06-10
Summary: 3 new findings detected (1 critical, 2 warnings)
🆕 New Findings
- 🔴 Critical: P0 issue MKLImports PDB not included with packages #5805 aged 5 years (assigned but stalled)
- 🟡 Warning: 100+ untriaged issues detected
- 🟡 Warning: 100+ issues without milestone
📊 Metric Changes
- P0 issues:
—→1(🆕 First run) - P1 issues:
—→23(🆕 First run) - Untriaged:
—→100+(🆕 First run) - Open PRs:
—→14(🆕 First run) - CI health:
✅(backport.yml, locker.yml 100% success)
Note: This is the initial baseline run. Future updates will show deltas from previous runs.
Generated by Repo Health Check — Orchestrator
🔍 Investigation:
I1-P0-5805Finding: P0 issue #5805 (MKLImports PDB) open for 5 years with assignee
Severity: critical
Category: issue
Issue: #5805
Evidence
-
Issue filed May 25, 2021 — 5 years ago, reported by
@ericstj(Microsoft team member with site_admin privileges)- Source: Issue MKLImports PDB not included with packages #5805 created_at: 2021-05-25T18:36:53Z
-
Last activity June 2, 2021 — No comments or updates in nearly 5 years
- Source: Issue MKLImports PDB not included with packages #5805 updated_at: 2021-06-02T16:39:26Z
-
Assignee present but inactive —
@michaelgsharpassigned, but no progress updates- Source: Issue MKLImports PDB not included with packages #5805 assignee field
-
Manual build process still in use — Documentation at
docs/building/MlNetMklDeps/README.mddescribes manual Windows/Linux/macOS build steps requiring Intel MKL SDK- Source: docs/building/MlNetMklDeps/README.md:23-69
-
Current version 0.0.0.12 — Built with Intel MKL 2021.3 (version.md updated but issue not addressed)
- Source: eng/Versions.props:48, docs/building/MlNetMklDeps/version.md:18-19
-
PDB generation documented but not enforced — README notes how to create PDBs (
/DEBUG:FULL /PDB:MklImports.pdbin makefile) but this is optional- Source: docs/building/MlNetMklDeps/README.md:49
-
No related PRs — Search for "5805" found only unrelated PRs (Nuget feed update #5701 nuget feed rename, Updating version after release #5642 version bump)
- Source: github-search_pull_requests
-
Issue author also requested scope expansion — Comment on June 2, 2021 suggested updating MKL version and ensuring consistency across platforms (related to Tests hang due to MKL loading blocking all threads #1073)
- Source: Issue MKLImports PDB not included with packages #5805 comment by ericstj at 2021-06-02T16:39:26Z
Root Cause
Confidence: High
The issue remains unresolved due to process neglect compounded by manual build friction:
-
Manual process barrier: MKLImports requires manual builds using Intel's proprietary MKL SDK, which developers must download and configure separately for Windows/Linux/macOS. The process is documented but not automated or integrated into CI.
-
Missing enforcement: PDB generation is documented as optional (
/DEBUG:FULLflag in makefile) rather than mandatory. Without CI automation to validate symbol presence, the manual builder can skip this step. -
Lack of ownership transition: Issue was assigned to
@michaelgsharpin 2021 but no follow-up occurred. No handoff, no milestone, no tracking in project boards. -
Low visibility: The issue is labeled P0 but has had zero activity for 5 years. It was likely triaged as "important" but never scheduled for actual work due to competing priorities and the friction of the manual build process.
The MlNetMklDeps package was updated to v0.0.0.12 (MKL 2021.3) since the issue was filed, but PDB inclusion was not addressed during that update, confirming the build process does not enforce symbol generation.
Recommendations
Priority Action Who 🔴 Immediate Re-triage or close: Determine if PDB symbols for MKLImports are still required. If Intel MKL is being phased out (e.g., in favor of oneDNN per README-oneDAL.md), close as won't-fix with explanation. If still needed, escalate to PM for scheduling. @dotnet/mlnet-maintainers🟡 Short-term Document workaround: If symbols are needed urgently, document how to manually rebuild MKLImports with PDBs enabled and publish updated package to machinelearning-assets feed. Update version.md to indicate v0.0.0.13+ includes PDBs. @michaelgsharpor assigned developer🟡 Short-term Add CI validation: Create a build validation step that fails if any native binary in a NuGet package lacks corresponding PDB/symbol files. This prevents regression. Build infrastructure team ℹ️ Long-term Automate MKL build: Integrate MKLImports build into main CI pipeline as optional job (requires Intel MKL SDK in build agent or cached), removing reliance on manual process. Consider Helix for platform-specific builds. Build infrastructure team ℹ️ Long-term Evaluate alternatives: Assess if Intel MKL can be replaced entirely with oneDNN (already in use per README-oneDAL.md) or other OSS alternatives to eliminate proprietary dependency and manual build process. Architecture review
Related
- Issue Tests hang due to MKL loading blocking all threads #1073 — Tests hang due to MKL loading (closed, related to version consistency)
- Issue AutoML should skip/ignore trainers that don't work on the current machine #5576 — AutoML should skip trainers when MKL unavailable (open, symptom of manual process friction)
- README-oneDAL.md — Repo already uses oneDNN for some operations, suggesting gradual MKL deprecation
- Azure feed
machinelearning-assets— Hosts MlNetMklDeps packages manually uploaded
Summary
Issue #5805 is a 5-year-old zombie issue labeled P0 but abandoned after initial triage. The root cause is manual build process friction combined with optional PDB generation and lack of ownership. Immediate action needed: either close as won't-fix if MKL is being phased out, or escalate and schedule if symbols are genuinely required. Long-term, the manual build process should be automated or eliminated.
Investigated by repo-health-investigate • Finding:
I1-P0-5805• Timestamp: 2026-06-10Generated by Repo Health — Investigate Finding
-
🔍 Investigation:
I3-untriaged-highFinding: 100+ untriaged issues (many workflow automation failures)
Severity: high
Category: issue
Evidence
- 821 open issues without milestone — Source: GitHub Search
is:open no:milestonereturned 821 results, 100 sampled - 221 issues with explicit "untriaged" label — Source: GitHub Search
is:open label:untriaged - 8 bot-created issues without milestone, 7 with untriaged label — Source: Cross-reference of bot author + no milestone
- 60% of no-milestone issues are from 2024 — 60/100 sampled issues created in 2024, 25 from 2025, 15 from 2026
- 5 recent workflow automation failure issues — Issues [agentics] Repo Health — Investigate Finding failed #7619, [aw] Code Review (machinelearning) failed #7618, [agentics] Repo Health — Dashboard Groomer failed #7617, [agentics] Repo Health Check — Orchestrator failed #7616 (all "[agentics]" or "[aw]" prefixes, all with
untriaged+agentic-workflowslabels) - Tracking issues exist but are untriaged themselves — [agentics] Failed runs #7615 (Failed runs parent), [agentics] No-Op Runs #7613 (No-Op runs parent), 🏥 Repo Health Dashboard #7612 (Repo Health Dashboard) all have
untriagedlabel - Majority of untriaged issues have other labels — Average 1.97 labels per no-milestone issue; 93% of
untriaged-labeled issues have additional labels (enhancement, bug, agentic-workflows, etc.)
Root Cause
Confidence: High
The "untriaged" finding conflates two distinct problems:
-
Definition ambiguity: "Untriaged" is measured two ways:
- No milestone = 821 issues (broad definition)
untriagedlabel = 221 issues (narrow definition)
The repo uses both the
untriagedlabel AND milestone assignment to signal triage status. The 821-issue count includes ~600 issues from 2024 that may have been partially triaged (labeled as bug/enhancement but never milestoned). These are "triaged but unprioritized," not "untriaged." -
Workflow automation issues lack triage automation: The recent surge of bot-created failure issues ([agentics] Repo Health — Investigate Finding failed #7619, [aw] Code Review (machinelearning) failed #7618, [agentics] Repo Health — Dashboard Groomer failed #7617, [agentics] Repo Health Check — Orchestrator failed #7616, [agentics] Failed runs #7615, [agentics] No-Op Runs #7613, 🏥 Repo Health Dashboard #7612) all retain the
untriagedlabel. These are meta-issues (tracking workflow health, not product bugs), yet they're counted alongside user-reported bugs. No automation removesuntriagedfrom these tracking issues, despite their purpose being informational.
The workflow automation failures themselves are transient (with expiration dates like "expires on Jun 14, 2026") but inflate the untriaged count while active.
Recommendations
Priority Action Who 🔴 Immediate Exclude tracking issues from triage metrics: Exclude issues with agentic-workflowsorrepo-healthlabels from "untriaged" counts. These are informational, not actionable by maintainers.Repo Health automation 🟡 Short-term Milestone sweep for 2024 issues: Triage the 60 oldest no-milestone issues (all from 2024) — assign to "Future" milestone or close if obsolete. Target: reduce no-milestone count by 100+ in one pass. Maintainers ( @dotnet/mlnet-maintainers)🟡 Short-term Auto-remove untriagedfrom bot-created tracking issues: Modify workflow automation to not applyuntriagedto parent/tracking issues (#7615, #7613, #7612) or remove it immediately after creation.GitHub Actions workflow ℹ️ Long-term Standardize triage definition: Document whether "triaged" means "has milestone" OR "lacks untriagedlabel" (not both). Reconcile the 600-issue gap.Maintainers + CONTRIBUTING.md update ℹ️ Long-term Auto-triage bot for old issues: Add automation to assign "Future" milestone to issues older than 90 days without milestone (or prompt for closure). GitHub Actions workflow
Related
- Issues [agentics] Repo Health — Investigate Finding failed #7619, [aw] Code Review (machinelearning) failed #7618, [agentics] Repo Health — Dashboard Groomer failed #7617, [agentics] Repo Health Check — Orchestrator failed #7616: Recent workflow automation failures (self-healing via debug agent invocation)
- Issues [agentics] Failed runs #7615, [agentics] No-Op Runs #7613: Tracking issues for workflow outcomes (should not be triaged like bugs)
- 821 no-milestone issues: Bulk includes 600 from 2024 that may be partially triaged (labeled but not prioritized)
untriagedlabel definition: Created with description "New issue has not been triaged" but applied inconsistently to old issues
Data Snapshot (2026-06-10)
No-milestone breakdown by year (first 100):
- 2026: 15 issues
- 2025: 25 issues
- 2024: 60 issues
untriagedlabel breakdown by year (all 221):- 2026: 14 issues
- 2025: 6 issues
- 2024+: 201 issues
Bot-created untriaged issues (7):
- [ci-scan-feedback] KPI Tracker #7621 — [ci-scan-feedback] KPI Tracker
- [agentics] Repo Health — Investigate Finding failed #7619 — [agentics] Repo Health — Investigate Finding failed
- [aw] Code Review (machinelearning) failed #7618 — [aw] Code Review (machinelearning) failed
- [agentics] Repo Health — Dashboard Groomer failed #7617 — [agentics] Repo Health — Dashboard Groomer failed
- [agentics] Repo Health Check — Orchestrator failed #7616 — [agentics] Repo Health Check — Orchestrator failed
- [agentics] Failed runs #7615 — [agentics] Failed runs
- [agentics] No-Op Runs #7613 — [agentics] No-Op Runs
Investigated by repo-health-investigate • Finding:
I3-untriaged-high• 2026-06-10Generated by Repo Health — Investigate Finding
- 821 open issues without milestone — Source: GitHub Search
📊 Daily Health Delta — 2026-06-11 07:31 UTC
Overall: 🟡 Warning (unchanged) | Findings: 3 → 4 (+1 new, 0 resolved)
Changes Since Yesterday (2026-06-10 07:21 UTC)
Type Count Details 🆕 New findings 1 Stale PRs (>30 days no activity) ✅ Resolved 0 — 📌 Existing 3 P0 issue, untriaged backlog, no-milestone backlog
🆕 New Findings
🟡 Stale PRs detected (
P5-stale-prs)4 confirmed stale PRs (no activity >30 days):
PR Title Last Activity #7609 Enable SymSgdNative on arm64 via system BLAS 37 days ago #7416 update torchsharp to 0.105.0 >15 months ago #7406 [GenAI] Use BitsAndBytes for 4bit quantization >15 months ago #6664 (WIP) Generic DataFrame Math >3 years ago Investigation dispatched.
📈 Key Metric Changes
Metric Yesterday Today Δ Open PRs 14 17 ↑ +3 New PRs opened — 2 #7625 (SentencePiece tokenizer), #7623 (report-green pipeline) Total findings 3 4 ↑ +1 CI workflows ✅ ✅ →
⚠️ CI SignalIssue #6978 (
blocking-clean-ci) — "TorchSharp TestSimpleQA killed / exit 137 (OOM)" — was updated today at 07:00 UTC. This is a long-standing CI flakiness issue. Monitor for recurrence.
📌 Existing Findings (No Change)
- 🔴 P0 MKLImports PDB not included with packages #5805 (Day 2): MKLImports PDB — awaiting team decision on re-triage vs. close (investigation)
- 🟡 221+ untriaged issues (Day 2): Stable count — includes workflow automation issues (investigation)
- 🟡 821+ issues without milestone (Day 2): Stable — bulk triage of 2024 issues recommended
Generated by Run #27331139767
Note
🔒 Integrity filter blocked 146 items
The following items were blocked because they don't meet the GitHub integrity level.
- large models loading with mlcontext.model.load ends up OutOfMemoryException #6948
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - After upgrading to .NET 7.0, I'm getting "PositiveRecall" is not supported. Why? #6472
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - DataFrame.OrderBy(string columnName) does not perform stable sorting! #6443
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - KMeans cluster analysis is non-deterministic when using KMeansYinyang initialization, even with fixed MLContext seed #6375
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Suspicious fragments found by PVS-Studio Static Analyzer #6321
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Error while using Model.Save() #6281
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - VectorType attribute with dynamic dimension while dealing with csv files #6151
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Microsoft.Data.Analysis DataFrame.Join infinite loop #6128
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Fix Recursive Parsing for PFI #6084
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - File path and/or name are too long when saving training model. #6036
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - IndexOutOfRangeException at Microsoft.ML.Data.BufferBuilder`1.AddFeature #6035
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - 'Probability' column missing in output schema of NaiveBayes MulticlassClassification trainer #6033
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - BufferBuilder.MakeDense: IndexOutOfRangeException #6032
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Memory leak when using ML.NET and TensorFlow.NET. #6005
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Cursor.MoveNext() gets stuck #5926
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Loading time of 2MB ML model is significantly slower in .NET Core compared to .NET Framework #5913
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - ... and 130 more items
To allow these resources, lower
min-integrityin your GitHub frontmatter:tools: github: min-integrity: approved # merged | approved | unapproved | none
Generated by Repo Health Check — Orchestrator · ● 617.9K · ◷
🔍 Investigation:
P5-stale-prsFinding: 4+ stale PRs with no activity >30 days: #7609, #7416, #7406, #6664
Severity: Medium
Category: PR
Evidence
-
PR Enable SymSgdNative on arm64 via system BLAS #7609 (
Enable SymSgdNative on arm64 via system BLAS, 37d stale) — External community PR fromanicka-net. All x64 CI jobs pass; all 8 arm64 cross-compilation CI jobs fail (Ubuntu_x64_cross_arm64, Windows_cross_arm64, MacOS_cross_arm64, Ubuntu_x64_cross_arm — both debug/release). Root cause:find_package(BLAS)in the newMklImportsArm/CMakeLists.txtlikely fails in the CI cross-compilation environment (no target-arch BLAS headers/libs available on the x64 host). CLA signed, zero human review. — Source: PR check runs -
PR update torchsharp to 0.105.0 #7416 (
update torchsharp to 0.105.0, 15mo stale) — Internal PR byLittleLittleCloud. Explicitly blocked per comment (2025-03-31) bymichaelgsharp: "newer versions don't support OSX-x64", requiring additional work to gate TorchSharp off on that platform before merging. Merge conflicts (dirty). — Source: PR comment -
PR [GenAI] Use BitsAndBytes for 4bit quantization. #7406 (
[GenAI] Use BitsAndBytes for 4bit quantization, 15mo stale) — Internal PR byLittleLittleCloud. Blocked by unresolved governance concern: the new dependencyLittleLittleCloud.TorchSharp.BitsAndBytesis a personal-repo package (not Microsoft-owned); reviewermichaelgsharpasked about ownership and centralized version pinning. Author confirmed the C# wrapper is in their personal repo (MIT). Merge conflicts (dirty). — Source: unresolved PR review thread -
PR (WIP) Generic DataFrame Math #6664 (
(WIP) Generic DataFrame Math, 3yr stale) — WIP PR byJakeRadMSFTtargetingfeature/4.0(notmain). Massive change (+2,992 / -43,986 lines; 80 files). Zero PR comments. Branchfeature/4.0still exists but appears dormant (latest commits are from 2023). No CI, no review, no update since 2023-07-06. — Source: PR metadata
Root Cause
Confidence: High
The four PRs represent distinct failure modes:
- Enable SymSgdNative on arm64 via system BLAS #7609: Genuinely valuable community fix blocked by a CI environment limitation (cross-compilation BLAS discovery) and lack of any maintainer review routing.
- update torchsharp to 0.105.0 #7416 / [GenAI] Use BitsAndBytes for 4bit quantization. #7406: Internal PRs by the same author abandoned mid-stream due to unresolved technical/governance blockers that were never tracked as issues or follow-up tasks.
- (WIP) Generic DataFrame Math #6664: Effectively abandoned WIP targeting a long-dormant feature branch; should be closed to reduce noise.
The common thread is no owner is actively driving any of these to resolution.
Recommendations
Priority Action Who 🔴 Immediate #7609: Assign a maintainer to review; check if arm64 cross-compile CI failures are pre-existing on mainor specific to this PR. If pre-existing, the PR itself is correct and CI needs fixing.Maintainers 🔴 Immediate #6664: Close as stale WIP — the base feature/4.0branch is dormant, the change is 3 years old and massively conflicts. If the generic math refactor is still wanted, file a fresh issue.JakeRadMSFTor maintainers🟡 Short-term #7416: Create a tracking issue for the OSX-x64 TorchSharp skip work so it's not lost; close this PR and reopen once the prerequisite is done. LittleLittleCloud/michaelgsharp🟡 Short-term #7406: Resolve governance question — should LittleLittleCloud.TorchSharp.BitsAndBytesbe donated to Microsoft or kept as an external dep? Either decide to merge with an explicit external-dependency policy statement, or close the PR.LittleLittleCloud/michaelgsharpi️ Long-term Add a stale-PR bot (e.g., actions/stale) with a 60-day policy to auto-comment and flag PRs without activity, surfacing these sooner.Repo maintainers
Related
- Issue Add substitutes for 4 IntelMKL methods so SymSgd can be added to non x86/x64 builds #5798 — ARM64 SymSGD support (addressed by Enable SymSgdNative on arm64 via system BLAS #7609)
- Issues Error: "Microsoft.ML currently supports 'x64' and 'x86' processor" when target runtime is *linux-arm* or *linux-arm64* #6588, Unable to load shared library 'MklImports' on MacOS with CLI #7229 — Related ARM platform work
feature/4.0branch — base for (WIP) Generic DataFrame Math #6664 (dormant)
Investigated by repo-health-investigate • Finding:
P5-stale-prsGenerated by Repo Health — Investigate Finding · ● 369.2K · ◷
-
📊 Health Check Delta — 2026-06-12
Category Count 🆕 New findings 0 ✅ Resolved findings 0 📌 Existing (unchanged) 3 📋 Reclassified as baselined 1 🔍 Investigators dispatched 0 Key Changes
📋 P0 #5805 → BASELINED (was CRITICAL for Days 1–2): Previous runs incorrectly flagged issue #5805 as critical because
.github/health-baseline.mdwasn't being loaded. Today the baseline file was successfully read — #5805 is listed there as "Known packaging tech debt (P0, open since 2021)", baselined 2026-03-06. This corrects the overall status from "1 critical + 3 warnings" to "0 critical + 3 warnings". Similarly, 3 stale PRs flagged yesterday (#7416, #7406, #6664) are now correctly shown as baselined; only #7609 (38 days inactive) remains a non-baselined stale PR.Stale PR warning updated: Of the 4 PRs flagged stale yesterday, 3 are baselined. Only #7609 (Enable SymSgdNative on arm64, 38+ days no activity) is a non-baselined stale PR awaiting review.
Issue #6978 still active: TorchSharp OOM test (
blocking-clean-ci) was updated again today (2026-06-12T07:00 UTC), indicating continued intermittent CI failures. Watching for escalation.No new issues opened or closed in the last 24h.
CI workflows healthy:
backport.yml(8 runs, all completed normally) andlocker.yml(run #924, success) are operating normally.Stable Warnings (no change)
- 🟡 221+ untriaged issues (Day 3) — View
- 🟡 821+ issues without milestone (Day 3) — View
- 🟡 Enable SymSgdNative on arm64 via system BLAS #7609 stale PR (Day 2) — #7609 arm64 SymSgd, 38+ days inactive
Generated by Repo Health Check — Orchestrator · Run #27401384283
Note
🔒 Integrity filter blocked 143 items
The following items were blocked because they don't meet the GitHub integrity level.
- large models loading with mlcontext.model.load ends up OutOfMemoryException #6948
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - After upgrading to .NET 7.0, I'm getting "PositiveRecall" is not supported. Why? #6472
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - DataFrame.OrderBy(string columnName) does not perform stable sorting! #6443
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - KMeans cluster analysis is non-deterministic when using KMeansYinyang initialization, even with fixed MLContext seed #6375
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Suspicious fragments found by PVS-Studio Static Analyzer #6321
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Error while using Model.Save() #6281
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - VectorType attribute with dynamic dimension while dealing with csv files #6151
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Microsoft.Data.Analysis DataFrame.Join infinite loop #6128
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Fix Recursive Parsing for PFI #6084
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - File path and/or name are too long when saving training model. #6036
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - IndexOutOfRangeException at Microsoft.ML.Data.BufferBuilder`1.AddFeature #6035
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - 'Probability' column missing in output schema of NaiveBayes MulticlassClassification trainer #6033
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - BufferBuilder.MakeDense: IndexOutOfRangeException #6032
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Memory leak when using ML.NET and TensorFlow.NET. #6005
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Cursor.MoveNext() gets stuck #5926
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Loading time of 2MB ML model is significantly slower in .NET Core compared to .NET Framework #5913
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - ... and 127 more items
To allow these resources, lower
min-integrityin your GitHub frontmatter:tools: github: min-integrity: approved # merged | approved | unapproved | none
Generated by Repo Health Check — Orchestrator · ● 713.8K · ◷
📅 Daily Health Delta — 2026-06-13 07:12 UTC
Run: #27459994584 | Status: 🟡 Warning (stable)
Finding Changes
Metric Previous (2026-06-12) Current (2026-06-13) Change 🔴 Critical 0 0 → 🟡 Warnings 3 3 → 📋 Baselined 24+ 24+ → ✅ Resolved 0 0 → 🆕 New findings 0 0 → Existing Warnings (no change in severity)
Finding Age Status 221+ untriaged issues Day 3 📌 Existing 821+ issues without milestone Day 3 📌 Existing PR #7609 stale (39d, non-baselined) Day 2 📌 Existing Notable Activity Since Yesterday
- 🆕 PR #7623 opened — Add report-green AzDO pipeline for build-excluded PRs (review pending)
- 🆕 PR #7625 opened (draft) — Add SentencePieceTokenizer factory methods for Unigram
- 🔄 Issue #6978 updated today — TorchSharp CI-blocking test (OOM/exit 137) remains active
- ✅ Locker workflow run Tests need their own environment implementation #925 succeeded (2026-06-12)
Key Metrics
Metric Value Open PRs ~19 (↑2 vs yesterday) P0 issues 1 (📋 BASELINED) P1 issues 23 Open bugs 59+ AzDO monitoring ⚠️ Disabled (no AZDO_PAT)No investigators dispatched — no new critical or warning findings this run.
Note
🔒 Integrity filter blocked 146 items
The following items were blocked because they don't meet the GitHub integrity level.
- #7610
list_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #7606
list_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #7605
list_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #7569
list_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #7094
list_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - #6449
list_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - large models loading with mlcontext.model.load ends up OutOfMemoryException #6948
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - After upgrading to .NET 7.0, I'm getting "PositiveRecall" is not supported. Why? #6472
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - DataFrame.OrderBy(string columnName) does not perform stable sorting! #6443
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - KMeans cluster analysis is non-deterministic when using KMeansYinyang initialization, even with fixed MLContext seed #6375
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Suspicious fragments found by PVS-Studio Static Analyzer #6321
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Error while using Model.Save() #6281
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - VectorType attribute with dynamic dimension while dealing with csv files #6151
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Microsoft.Data.Analysis DataFrame.Join infinite loop #6128
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Fix Recursive Parsing for PFI #6084
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - File path and/or name are too long when saving training model. #6036
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - ... and 130 more items
To allow these resources, lower
min-integrityin your GitHub frontmatter:tools: github: min-integrity: approved # merged | approved | unapproved | none
Generated by Repo Health Check — Orchestrator · ● 1.1M · ◷
Quick maintainer summary for #7612:
- I found 5 open PR(s) currently linked to this issue: Add public SentencePieceTokenizer factory methods for Unigram from vocab list and tokenizer.json #7625, Add report-green AzDO pipeline so Build Analysis completes on build-excluded PRs #7623, Fix SR-CNN missing anomalies when Period > 0 #7610, Enable SymSgdNative on arm64 via system BLAS #7609, Upgrade to V4 arcade publishing #7606.
- Add public SentencePieceTokenizer factory methods for Unigram from vocab list and tokenizer.json #7625: Add public SentencePieceTokenizer factory methods for Unigram from vocab list and tokenizer.json; draft; does not show explicit test/build output in the PR body.
- Add report-green AzDO pipeline so Build Analysis completes on build-excluded PRs #7623: Add report-green AzDO pipeline so Build Analysis completes on build-excluded PRs; open; includes validation notes.
- Fix SR-CNN missing anomalies when Period > 0 #7610: Fix SR-CNN missing anomalies when Period > 0; open; includes validation notes.
- Enable SymSgdNative on arm64 via system BLAS #7609: Enable SymSgdNative on arm64 via system BLAS; open; includes validation notes.
Suggested next step: review the PR with the clearest verification first, then ask overlapping PRs to rebase, trim scope, or confirm what remains distinct.
📊 Daily Delta — 2026-06-14 07:30 UTC
Status: 🟡 Warning (unchanged from yesterday)
Count 🆕 New findings 0 ✅ Resolved findings 0 📌 Existing (persisting) 3 📋 Baselined 24+ Persisting Warnings (no change):
- 📌 EXISTING (Day 4) — 221+ untriaged issues
- 📌 EXISTING (Day 4) — 821+ issues without milestone
- 📌 EXISTING (Day 3) — 1 stale non-baselined PR (#7609, ~40 days inactive)
Notable activity since yesterday:
- Issue #6978 (TorchSharp OOM,
blocking-clean-ci) was updated today at 07:00 UTC — active CI issue, still open
CI health: ✅
backport.ymlhealthy | ✅locker.ymlrun #926 success (2026-06-13) |⚠️ AzDO not monitored (no AZDO_PAT)No new dispatches — all existing warnings have prior investigation results.
Run #27491913763
Note
🔒 Integrity filter blocked 103 items
The following items were blocked because they don't meet the GitHub integrity level.
- large models loading with mlcontext.model.load ends up OutOfMemoryException #6948
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - After upgrading to .NET 7.0, I'm getting "PositiveRecall" is not supported. Why? #6472
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - DataFrame.OrderBy(string columnName) does not perform stable sorting! #6443
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - KMeans cluster analysis is non-deterministic when using KMeansYinyang initialization, even with fixed MLContext seed #6375
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Suspicious fragments found by PVS-Studio Static Analyzer #6321
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Error while using Model.Save() #6281
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - VectorType attribute with dynamic dimension while dealing with csv files #6151
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Microsoft.Data.Analysis DataFrame.Join infinite loop #6128
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Fix Recursive Parsing for PFI #6084
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - File path and/or name are too long when saving training model. #6036
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - IndexOutOfRangeException at Microsoft.ML.Data.BufferBuilder`1.AddFeature #6035
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - 'Probability' column missing in output schema of NaiveBayes MulticlassClassification trainer #6033
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - BufferBuilder.MakeDense: IndexOutOfRangeException #6032
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Memory leak when using ML.NET and TensorFlow.NET. #6005
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Cursor.MoveNext() gets stuck #5926
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - Loading time of 2MB ML model is significantly slower in .NET Core compared to .NET Framework #5913
list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved". - ... and 87 more items
To allow these resources, lower
min-integrityin your GitHub frontmatter:tools: github: min-integrity: approved # merged | approved | unapproved | none
Generated by Repo Health Check — Orchestrator · ● 506.4K · ◷
- locked and limited conversation to collaborators
on Aug 2, 2026
🏥 ML.NET Repository Health Dashboard
Last Updated: 2026-06-14 07:30 UTC
Overall Status: 🟡 Warning
Last Groomed: 2026-06-14 10:13 UTC (Dashboard Groomer #27495615270)
Counts: 3 warnings, 0 critical | 24+ items correctly baselined
📊 Executive Summary
Repository health remains in warning state, stable for Day 4. No new findings since yesterday — the three existing warnings (untriaged backlog, issues without milestones, one stale non-baselined PR) continue unchanged. Issue #6978 (TorchSharp OOM,
blocking-clean-ci) was updated again today. CI workflows remain healthy. AzDO pipeline monitoring is disabled (no AZDO_PAT).🔍 Findings
🔴 Critical
None — P0 issue #5805 is correctly classified as BASELINED (see below).
🟡 Warnings
📋 Baselined (accepted known items)
i️ Informational
✅ Recently Resolved / Reclassified
.github/health-baseline.mdas "Known packaging tech debt (P0, open since 2021)" baselined 2026-03-06.📈 Trends (7-day)
🔗 Configuration
Repository: dotnet/machinelearning⚠️ Monitoring disabled —
Tracked GitHub Actions:
backport.yml,locker.ymlAzure DevOps:
AZDO_PATnot configured (dnceng/public: vsts-ci, codecoverage-ci, night-build, outer-loop-build)Priority Labels: P0, P1, P2, P3, bug
Baseline:
.github/health-baseline.md✅ Found — 24 issues + 6 PRs baselinedInvestigators Dispatched this run: 0 (no new critical/warning findings)
Last Workflow Run: #27491913763
This dashboard is automatically updated daily by the
repo-health-checkworkflow.