Workflow Health

Read-only baseline for CI, scheduled jobs, artifact refresh, Dependabot, CodeQL, and release signals across the organization.

Workflow Score Distribution

Each active repository receives a workflow health score based on which CI automation signals are present: a base score for having any workflows, with bonuses for scheduled jobs, artifact-refresh pipelines, CI/test/build workflows, deploy pipelines, and formal releases. The histogram shows whether repos cluster at the top (well-automated) or the bottom (no automation at all), and where the biggest improvement opportunities are.

How to read: Each bar is one score level; colour codes the tier: green ≥ 6 (well-automated), amber 3–5 (partial), red < 3 (minimal or none). Example 1: A large red bar at score 0 means many repos have no GitHub Actions at all — no CI, no scheduled jobs, no releases — the org's baseline automation level. Example 2: A small peak at the maximum score identifies a well-configured cluster; those repos are the templates to copy when setting up automation for others.

Conclusion: A distribution with most repos at score 0–2 is expected for a project where most content repos are simple dictionary text holders that need no CI. However, tooling repos (csl-websanlexicon, csl-apidev, csl-pywork) scoring below 3 would be a genuine concern — those are the repos where automation failures have direct impact on the live public site.

Automation Signals

For each of six automation categories — GitHub Actions workflows, scheduled jobs, artifact/refresh pipelines, CI/test/build, deploy/pages, and formal releases — this chart shows how many repos have that signal present vs missing. The split across six categories reveals which automation types are widespread and which are rare, pointing to org-wide gaps that could be addressed with a shared template or runbook.

How to read: Each row is one automation type; bars stack "present" (green) vs "missing" (red). Example 1: If "Workflows" shows most repos as "present" but "Scheduled" shows mostly "missing," repos have adopted basic CI but have not configured any recurring automated tasks — data refresh or periodic health checks are not running. Example 2: A "Releases" row that is mostly "missing" means repos are not making formal tagged releases — important for reproducibility and scholarly citation.

Conclusion: Releases and scheduled jobs are typically the last automation layers to be adopted; their absence across most repos is expected but should be remedied for any repo whose data outputs are intended to be citable. A single shared release workflow template could bring many repos from 0 to 1 releases with minimal per-repo effort.

Dependency And Security Coverage

Dependabot (automated dependency update PRs) and CodeQL (GitHub's static security analysis) are the two security-focused automation signals tracked per repository. Both require opting in via configuration files. For pure-data dictionary repos the risk is low, but for web-facing infrastructure repos (csl-apidev, csl-websanlexicon), the absence of these tools is a concrete security gap — dependency vulnerabilities go unpatched until a maintainer manually notices them.

How to read: Each row is one security tool; bars stack "yes" (green), "no" (red), "unknown" (amber). Example 1: If Dependabot is "yes" for only a handful of repos, most dependency updates — including security patches — are happening manually or not at all. Example 2: A large "unknown" segment for CodeQL means the data snapshot could not confirm its status — re-check after a live refresh before concluding it is absent.

Conclusion: Low Dependabot and CodeQL coverage is the org's primary security-automation gap. For pure-data repos this is low risk; for web-facing repos running production infrastructure, lack of automated dependency updates is an addressable vulnerability. Dependabot can be enabled with a single .github/dependabot.yml file — one file, one repo, immediate improvement.

Flag Mix

A ranked breakdown of which specific workflow-health flags appear most frequently across the org's active repositories. Each flag represents one concrete automation gap (no-workflows, no-scheduled-job, no-releases, etc.). The rank order tells maintainers whether gaps are systemic — affecting many repos and addressable with a shared template — or isolated — affecting specific repos requiring individual attention.

How to read: Each bar is one flag type; length = repos carrying that flag. Amber = "unknown" flags (data-snapshot gaps); red = confirmed automation gaps. Example 1: If "no-releases" is the longest bar, the most widespread single automation gap across the org is the absence of formal tagged releases — a systemic problem addressable with an org-level release-workflow template. Example 2: An amber "unknown" flag that appears frequently means the data snapshot has a consistent blind spot for that field — a live refresh should resolve most instances.

Conclusion: The flag mix converts per-repo workflow data into an org-wide action list. Flags at the top are systemic — worth addressing with a shared template that many repos can adopt. Amber unknown flags are data-quality problems that resolve with a live snapshot refresh and should not be treated as confirmed gaps until verified.

Action Queue

The 25 lowest-scoring repositories, sorted first by workflow health score (ascending) then by flag count (descending) — the repos that most need CI/automation attention this sprint. Unlike the ops-command action queue which scores across all risk dimensions, this queue focuses specifically on workflow and release automation gaps. The sortable table lets maintainers drill into the specific missing signals for each repo.

How to read: Each row is one repo; columns show the score, specific workflow counts, Dependabot/CodeQL presence, release count, and the flags that lowered the score. Example 1: A repo with score 0, no workflows, no releases, and flags "no-workflows|no-releases" needs both a basic CI workflow file and a release process set up from scratch. Example 2: A repo with score 3, existing workflows, and flag "no-scheduled-job" is already partially automated — the specific gap is easy to add (a cron trigger on an existing workflow).

Conclusion: The workflow action queue is the maintainer's CI sprint list for this snapshot. Repos at the top (score 0, multiple flags) are completely unautomated and need setup from scratch. Repos lower in the queue (score 2–3, single remaining flag) need one targeted addition. Any tooling or web-facing repo appearing in this queue is higher priority than a pure-content dictionary repo with the same score.