/kb-github-analytics-scoring

name: kb-github-analytics-scoring
description: Reference data, not a reviewer. Score repository health (0-100, A-F grades), priorities, and delta tracking. Includes velocity metrics, confidence levels, and bottleneck detection.
license: MIT
disable-model-invocation: true
user-invocable: false
metadata:
  tier: reference
  domain: cross-cutting
  output: none
  effort: low
  title: Github Analytics Scoring

GitHub Analytics Scoring

Repository Health Score

Health Score = 100 - (sum of weighted penalties)

Penalties - CI & Reliability:
  Failing workflow, high confidence:         -10 points
  Flaky test (3+ failures/week):             - 5 points
  No CI configured:                          - 8 points

Penalties - Issues & PRs:
  Critical unresolved bug (P0):             -10 points
  Security alert (critical severity):       -10 points
  Security alert (high severity):           - 5 points
  PR open >14 days (stale):                 - 3 points each (max -9)
  Issue @mentioned, no response >7 days:    - 5 points each (max -10)
  >10 open issues with no labels/triage:    - 3 points

Penalties - Community Health:
  No CONTRIBUTING.md:                        - 5 points
  No CODE_OF_CONDUCT.md:                     - 3 points
  No branch protection or ruleset on default: - 5 points
  0 open "good first issue" labels:          - 2 points

Floor: 0 (minimum score)

Score Grades

Each score, with its grade and meaning.

| Score | Grade | Meaning | |-------|-------|---------| | 90-100 | A | Excellent - healthy repo, minimal issues | | 75-89 | B | Good - minor issues, well-managed | | 50-74 | C | Needs attention - multiple signals requiring action | | 25-49 | D | Poor - significant problems impacting velocity | | 0-24 | F | Critical - major issues blocking team progress |

---

Priority Scoring for Issues

Internally score each issue to determine sort order in dashboards and reports:

| Signal | Points | |--------|--------| | User @mentioned and hasn't responded | +5 | | `P0`, `P1`, `critical`, `urgent`, `blocker` label | +3 | | Tied to upcoming release milestone | +3 | | New comments from others since user's last activity | +2 | | High community interest (5+ positive reactions) | +2 | | `bug` label | +1 | | Assigned to user | +1 | | Active related discussion thread | +1 | | `wontfix`, `duplicate`, `question` label | -1 | | No activity >14 days | -2 |

Priority Scoring for Pull Requests

Each signal, with its points.

| Signal | Points | |--------|--------| | Review requested, user hasn't reviewed | +5 | | PR has "changes requested" - author needs to update | +4 | | PR is approved and ready to merge | +3 | | Targets a release branch with upcoming deadline | +3 | | CI failed on this PR | +2 | | Merge conflicts present | +2 | | High community interest (5+ positive reactions) | +2 | | New comments on the PR | +1 | | Active discussion thread linked to this PR | +1 | | Draft PR | -1 | | No activity >7 days | -2 |

Priority Scoring for Discussions

Each signal, with its points.

| Signal | Points | |--------|--------| | User was @mentioned | +3 | | High activity (10+ comments in 24h) | +2 | | Linked to an issue/PR the user owns | +1 | | No activity >7 days | -1 |

---

Confidence Levels for Analytics Findings

Apply confidence levels to all bottleneck findings, health score deductions, and anomaly detections. Every finding in a report MUST include its confidence level.

| Level | When to Use | Impact on Report | |-------|-------------|-----------------| | **High** | Multiple corroborating signals, definitively observed (e.g., CI has failed 5 times this week, confirmed by logs) | Report as fact; recommend remediation | | **Medium** | Found by one source, likely issue (e.g., PR open 14 days but author may be on leave) | Report as finding; suggest investigation | | **Low** | Possible pattern, needs human review (e.g., velocity seems low but may be seasonal) | Flag as observation; don't deduct from score |

Confidence Tag Format in Reports

| Finding | Severity | Confidence | Recommendation |
|---------|----------|-----------|----------------|
| 3 PRs stale >14 days | High | **High** | Assign reviewers or close |
| Velocity 40% below 4-week avg | Medium | **Medium** | Verify - may be holiday period |
| Issue activity spike on Fridays | Low | **Low** | Monitor for 2 weeks before acting |

---

Delta Tracking

When re-running an analysis against a previous report, classify every finding by change status:

| Status | Definition | |--------|-----------| | **Fixed** | Was in previous report; no longer present | | **New** | Not in previous report; appears now | | **Persistent** | Remains from previous report, unchanged | | **Regressed** | Was previously fixed but has returned |

Delta Report Section Format

## Changes Since Last Report ({previous date})

| Change | Finding | Details |
|--------|---------|---------|
| Fixed | 3 stale PRs resolved | Team cleared the backlog |
| New | CI failing on main | Build broke in last 24h |
| Persistent (#3) | Velocity 30% below baseline | Third consecutive week |
| Regressed | Security alert reopened | lodash advisory re-filed |

**Progress:** {N} fixed, {M} new, {P} persistent, {Q} regressed
**Score change:** {current_score} ({+/-N} from {previous_score})

Escalation Rule

If a finding is **Persistent for 3+ consecutive reports**, escalate:

> **Escalation:** [{Finding}] has been present for {N} consecutive reports. Consider a team discussion or explicit ownership assignment to resolve this.

---

Velocity Metrics

Each metric, with its formula, healthy, warning and critical.

| Metric | Formula | Healthy | Warning | Critical | |--------|---------|---------|---------|---------| | PR merge rate | PRs merged / week | >3/week | 1-3/week | <1/week | | Issue close rate | Issues closed / week | >5/week | 2-5/week | <2/week | | Review turnaround | Avg hours PR open before first review | <24h |