Problem
A maintainer running ORB on their repo has no visibility into how much of their contribution activity comes from AMS miners versus regular human contributors, or how that cohort actually performs (acceptance rate, review-cycle count, time-to-merge). ORB already has every GitHub login on every PR record it's reviewed; the only missing piece is a way to identify which of those logins are AMS miners, and a view that presents the comparison.
Area
apps/loopover-ui (a new maintainer-dashboard panel, likely alongside maintainer-panel.tsx), src/db/repositories.ts (a new aggregate query), possibly src/review/submitter-reputation.ts or wherever contributor-outcome history is already read from for that panel.
Proposal (open questions a design pass needs to answer — not yet decided)
- "What counts as an AMS miner": this is the central open question and depends on the identity-linkage decision from the sibling reputation-bridge spec (
#6206's other sub-issue) — do not duplicate that design work here; this analytics view should consume whatever identity signal that spec produces, once decided, rather than inventing its own.
- Metrics: acceptance rate, average review-cycle count, time-to-merge, and PR volume are the obvious candidates — confirm against what data
submitter-reputation.ts's existing review_targets-based classification already computes per-submitter, so this view reuses that logic rather than re-deriving outcome classification from scratch.
- Privacy: this is a maintainer-only, private dashboard view (bearer-gated, matching
submitter-reputation.ts's own /stats access model) — never a public comment, label, or check-run surface.
- Placement: a new panel/section, or an extension of an existing maintainer dashboard panel (
maintainer-panel.tsx)? Prefer extending an existing panel if the data shape fits, per this repo's general preference for reusing existing dashboard chrome over adding new pages.
Deliverables
Resources
src/review/submitter-reputation.ts (existing per-submitter outcome classification to reuse, not reinvent)apps/loopover-ui/src/components/site/app-panels/maintainer-panel.tsx (likely placement)#6206's reputation-bridge sub-issue (the identity-linkage decision this view depends on)
Boundaries
maintainer-only until the identity-linkage question (owned by the reputation-bridge sub-spec) is resolved — this view cannot be scoped independently of that decision.- Bearer-gated, maintainer-only visibility — never surfaced publicly.
- Should not become buildable/contributor-open before the reputation-bridge spec lands its identity decision, to avoid two independent implementations of "how do we know this login is an AMS miner."
Problem
A maintainer running ORB on their repo has no visibility into how much of their contribution activity comes from AMS miners versus regular human contributors, or how that cohort actually performs (acceptance rate, review-cycle count, time-to-merge). ORB already has every GitHub login on every PR record it's reviewed; the only missing piece is a way to identify which of those logins are AMS miners, and a view that presents the comparison.
Area
apps/loopover-ui(a new maintainer-dashboard panel, likely alongsidemaintainer-panel.tsx),src/db/repositories.ts(a new aggregate query), possiblysrc/review/submitter-reputation.tsor wherever contributor-outcome history is already read from for that panel.Proposal (open questions a design pass needs to answer — not yet decided)
#6206's other sub-issue) — do not duplicate that design work here; this analytics view should consume whatever identity signal that spec produces, once decided, rather than inventing its own.submitter-reputation.ts's existingreview_targets-based classification already computes per-submitter, so this view reuses that logic rather than re-deriving outcome classification from scratch.submitter-reputation.ts's own/statsaccess model) — never a public comment, label, or check-run surface.maintainer-panel.tsx)? Prefer extending an existing panel if the data shape fits, per this repo's general preference for reusing existing dashboard chrome over adding new pages.Deliverables
#6206's reputation-bridge sub-spec landing its own decision first), the metric set, and where in the existing dashboard this surfaces.Resources
src/review/submitter-reputation.ts(existing per-submitter outcome classification to reuse, not reinvent)apps/loopover-ui/src/components/site/app-panels/maintainer-panel.tsx(likely placement)#6206's reputation-bridge sub-issue (the identity-linkage decision this view depends on)Boundaries
maintainer-onlyuntil the identity-linkage question (owned by the reputation-bridge sub-spec) is resolved — this view cannot be scoped independently of that decision.