Ops Command Center

Maintainer-first operating view across repository health, metadata blockers, issue pressure, and bus-factor risk.

Risk Quadrant By Repo

Each repository is plotted as a dot combining two risk dimensions: open-issue pressure on the x-axis and a selectable second metric on the y-axis (hygiene flags, unknown metadata fields, or top contributor share). Dot size encodes the composite action score — a weighted sum of hygiene flags, metadata gaps, bus-factor penalty, and open issues. Red dots are highest priority: bus factor 1 with additional outstanding problems; green dots have at least two maintainers; amber covers repos whose bus-factor status is unknown.

How to read: Each dot is one repository; x = open issues, y = the metric selected in the dropdown above, dot size = action score. Switch the y-axis to explore different risk combinations. Example 1: A large red dot in the upper-right corner has high open-issue pressure AND high risk on the y-axis AND bus factor 1 — the worst combination, highest priority for action. Example 2: A small green dot near the origin is low-priority: few issues, low hygiene risk, and at least two maintainers who could continue the work.

Conclusion: The quadrant reveals which repos need attention on multiple fronts simultaneously. Repos in the upper-right are the highest-leverage targets; resolving their hygiene or bus-factor issues would have disproportionate impact on the org's overall risk profile.

Blocker Mix By Category

A summary inventory of the org's current hygiene blockers by category — the single most condensed "to-do list" view in the observatory. Each bar shows how many repositories carry that specific problem. Because the categories span licensing, metadata, contributor risk, and issue quality, the chart guides where to direct effort across very different workstreams.

How to read: Each bar is one blocker type; length = the number of repositories currently affected. Example 1: If "bus factor 1" is the longest bar, contributor concentration is more widespread than any licensing or branch issue — the priority is community-building, not cleanup scripts. Example 2: If "open unlabeled issues" shows a large count, that's a taxonomy-triage problem rather than a repository-health problem — the fix belongs in the coverage-page workflow, not here.

Conclusion: The blocker mix is the dashboard's prioritisation compass. After the RH1 license rollout, the licensing bars should be short; the dominant remaining blockers are expected to be bus factor, legacy branch naming, and metadata unknowns — each requiring a different kind of intervention.

Open Issue Pressure By License Class

Groups all open issues by the license class of the repository they live in. The goal is to see whether the active correction backlog sits in licensed or unlicensed repos. If unlicensed repos carry a disproportionate share of open issues, active scholarly correction work is happening in a legally ambiguous context — a combined hygiene-and-backlog risk that the RH1 rollout aimed to eliminate.

How to read: Each bar is one license class; height = total open issues across all repos in that class. Example 1: A tall "recognised" bar is normal and expected — most active repos are now licensed and their backlog sits in a clear legal frame. Example 2: Any non-trivial height in the "none" bar means active correction campaigns are running in repos with no usage license — the highest-priority combination for the cleanup decision queue.

Conclusion: After RH1, most open issues should sit in the "recognised" class. Any concentration in "none" or "unrecognised" identifies repos where active work is still happening without clear reuse rights — the most urgent overlap between hygiene and content priorities.

Top Action Queues

The 20 repositories with the highest composite action score, sorted by urgency. The action score is a weighted index: hygiene flags contribute 3 points each, unknown metadata blockers 2 each, open issues 1 each, and bus factor 1 adds a flat penalty of 4. This single number captures a repo's urgency across all dimensions so maintainers can work a prioritised queue rather than scanning dozens of charts.

How to read: Each bar is one repo; length = its composite action score. Amber bars are driven primarily by live-metadata unknowns; red bars by confirmed hygiene flags. Example 1: A long red bar means the repo has multiple confirmed hard flags AND a large open-issue backlog AND bus factor 1 — all problems at once, needing coordinated action. Example 2: A long amber bar may shrink after a live metadata refresh if the unknowns resolve to "yes" — always re-check amber-heavy repos against a current snapshot before acting.

Conclusion: The top action queue is the maintainer's immediate triage list. Work from the top down: resolve amber bars first with a live refresh, then address confirmed red bars in order. Hovering on each bar shows the breakdown of issues, flags, and metadata gaps, making it actionable without leaving this page.

Active Vs Clean Repo Matrix

A two-way matrix crossing each repo's default branch name against its hygiene status — clean (zero flags) or flagged. This tests whether legacy-branch repos and flagged repos are the same population or independent problems. If they are correlated, modernising the branch name and fixing hygiene tend to happen together; if they are independent, the branch rename can be targeted at a separate cohort.

How to read: Each cell shows the count of repos in that branch × hygiene-status combination; darker colour = more repos. Example 1: A dark cell at ("master", "flagged") means most repos with the legacy branch name also have other outstanding flags — the two problems cluster and should be addressed together. Example 2: A bright cell at ("main", "clean") shows the modernised-and-clean population — the target state every repo should eventually reach.

Conclusion: If "master"/"flagged" is the darkest cell, branch renaming and hygiene improvement are correlated — fixing one creates momentum for the other. If "master"/"clean" is also densely populated, branch naming is an isolated issue that a simple rename resolves without triggering any other hygiene work.

Back to overview