Dataface Tasks
    Heartbeat snapshot (JSON)

    Design GitHub OSS dashboard topology and metric contract

    IDDASHBOARD_FACTORY-DESIGN_GITHUB_OSS_DASHBOARD_TOPOLOGY_AND_METRIC_CONTRACT
    Statusnot_started
    Priorityp1
    Milestonem4-v1-0-launch
    Ownerdata-analysis-evangelist-ai-training
    Initiativegithub-oss-activity-dashboards

    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

    QA Exploration

    • [ ] 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

    • [ ] Review cleared