---

type: task id: DASHBOARD_FACTORY-DESIGN_GITHUB_OSS_DASHBOARD_TOPOLOGY_AND_METRIC_CONTRACT title: Design GitHub OSS dashboard topology and metric contract description: Define the board set, personas, metric families, entity grains, and cross-dashboard link matrix for GitHub repository and contributor analytics. milestone: m4-v1-0-launch owner: data-analysis-evangelist-ai-training status: not_started priority: p1 initiative: github-oss-activity-dashboards

---

Design GitHub OSS dashboard topology and metric contract

Problem

Define the board set, personas, metric families, entity grains, and cross-dashboard link matrix for GitHub repository and contributor analytics.

Context

• This task turns the initiative research into a concrete dashboard product shape:
• tasks/workstreams/dashboard-factory/initiatives/github-oss-activity-dashboards/research.md
• tasks/workstreams/dashboard-factory/initiatives/github-oss-activity-dashboards/spec.md
• GitHub already shows repo-local Pulse and Traffic views, but does not provide a polished multi-board static site with contributor drill-through.
• The dashboard suite needs to feel useful for real OSS maintainers, not just like vanity stats cards.
• Contributor detail is the central navigation requirement: summary boards should link to a stable per-person dashboard keyed by GitHub login.
• The output of this task should be strong enough that implementation can proceed without re-debating board scope or metric semantics.

Possible Solutions

1. Single summary board only - Lowest effort and easiest to ship. - Fails the user's request for interlinked dashboards and contributor drill-through.

2. Recommended: small interlinked board suite with contributor detail as the canonical drill-through - Keep v1 to five boards: overview, flow, reviews, contributors, contributor detail. - Gives enough surface area to tell a real project story without exploding implementation scope. - Matches the initiative goal of "better visibility than GitHub currently shows" while staying static-site friendly.

3. Full OSS intelligence suite from day one - Could add repository detail, adoption, retention, release, and sustainability dashboards immediately. - Too much scope for an M4 add-on; likely stalls before a credible v1 exists.

Plan

1. Lock the v1 board set, user personas, and primary question bank for each board.
2. Define the metric families and entity grains each board depends on.
3. Write the cross-board link matrix with contributor drill-through rules.
4. Call out explicit v1 exclusions so the implementation tasks do not drift into enterprise developer-productivity scope.
5. Feed the final topology and metric contract back into the initiative spec.md and downstream extraction / publishing tasks.

Implementation Progress

<!-- Technical details, key decisions, code changes. Append as work progresses. -->

QA Exploration

<!-- For UI/browser tasks: use Playwright MCP to explore the running app. Record bugs found, fixes applied, and suggestions for future work. Skip for non-UI tasks (mark N/A). -->

• [ ] QA exploration completed (or N/A for non-UI tasks)

N/A for browser QA. This is a planning and dashboard-architecture task.

Review Feedback

<!-- Reviewer comments, what was changed in response, and sign-off. -->

• [ ] Review cleared