activity summary should count private-repo work, not omit it #7

New Issue

grenade · 2026-08-15T17:31:34Z

grenade commented

2026-08-15 17:31:34 +00:00

/v1/activity/summary passes include_private: false, so the summary cards only ever count public activity. The contribution graph directly above them passes include_private: true. The two views therefore disagree, with nothing on the page explaining why:

a period spent mostly in private repos reads as near-idle beside a busy graph
a period spent entirely in private repos produces no card at all, so there is no way to see that the day was busy
the card headline ("N changes in M repositories") reports public volume while presenting itself as the period's total

Proposal

Alongside the named per-repo rows, emit at most one row per period aggregating that period's private-repo activity: private = true, source and repo null. RepoPeriodCount.source/.repo become nullable to carry it.

The card should count it towards the period's changes but never towards its repository count — the lump covers an unknown number of repos — and render it last, unlinked and without a language bar. A language mix on the aggregate would narrow it back down to the repo it is meant to be hiding.

Granularity

Per period only, not per (period, source). The per-period total is already derivable from /v1/activity/daily, which counts private activity, so publishing it adds nothing that isn't already on the contribution graph. A per-forge split would be genuinely new information.

The ?source= filter is the exception: it narrows the aggregate, which makes per-forge counts recoverable by diffing two requests. Accepted knowingly — a summary that contradicts the filter it was handed is the worse failure.

Note on `include_private`

The parameter keeps its meaning. With it set, the named branch takes everything and the aggregate is empty, so a future authenticated view sees repos rather than a lump.

`/v1/activity/summary` passes `include_private: false`, so the summary cards only ever count public activity. The contribution graph directly above them passes `include_private: true`. The two views therefore disagree, with nothing on the page explaining why: - a period spent mostly in private repos reads as near-idle beside a busy graph - a period spent **entirely** in private repos produces no card at all, so there is no way to see that the day was busy - the card headline ("N changes in M repositories") reports public volume while presenting itself as the period's total ### Proposal Alongside the named per-repo rows, emit at most one row per period aggregating that period's private-repo activity: `private = true`, `source` and `repo` null. `RepoPeriodCount.source`/`.repo` become nullable to carry it. The card should count it towards the period's changes but never towards its repository count — the lump covers an unknown number of repos — and render it last, unlinked and without a language bar. A language mix on the aggregate would narrow it back down to the repo it is meant to be hiding. ### Granularity Per period only, **not** per `(period, source)`. The per-period total is already derivable from `/v1/activity/daily`, which counts private activity, so publishing it adds nothing that isn't already on the contribution graph. A per-forge split would be genuinely new information. The `?source=` filter is the exception: it narrows the aggregate, which makes per-forge counts recoverable by diffing two requests. Accepted knowingly — a summary that contradicts the filter it was handed is the worse failure. ### Note on `include_private` The parameter keeps its meaning. With it set, the named branch takes everything and the aggregate is empty, so a future authenticated view sees repos rather than a lump.

grenade referenced this issue from a commit

2026-08-15 17:31:48 +00:00

feat: count private-repo work in the activity summary

grenade closed this issue

2026-08-15 17:31:48 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: grenade/moments#7

activity summary should count private-repo work, not omit it #7

Proposal

Granularity

Note on include_private

Note on `include_private`