Docs / Contribution counting
Profiles
How ForkMesh counts contributions
Every ForkMesh profile includes a native contribution card by default. It is built from signed ForkMesh repository activity and does not depend on GitHub, a GitHub username, or a profile README embed.
The card shows verified daily activity from public repositories only. Exact counts remain available in the chart labels, keyboard descriptions, activity timeline, and public profile API.
What is counted
ForkMesh counts five kinds of activity. Each event is assigned to one UTC date so the same signed source produces the same profile result in every timezone.
| Category | Counted event | Date and identity source |
|---|---|---|
| Commits | A commit reachable from the repository's published default branch. | The Git author timestamp in UTC, matched to the repository's configured Git identity. |
| Issues | A verified canonical issue open event. | The signed event timestamp and the registered event author key. |
| Pull requests | A verified new pull request. | The signed pull timestamp and the registered pull author key. |
| Reviews | A verified pull conversation event whose type is review. | The signed review timestamp and the registered review author key. |
| Repositories | The first accepted public publication of a logical repository. | The first public publication day recorded by the ForkMesh Worker. |
Not counted: private repository activity, pending inbox submissions, branch-only commits outside the published default branch, generated files, binary files, and unsupported language files.
Git identity and signed collaboration
Commit attribution uses the name and email in the repository's configured Git identity at publication time. The desktop node matches those values exactly against default-branch commits before it creates the contribution snapshot.
Issue, pull request, and review attribution comes from their signed ForkMesh records. The Worker resolves each verified author key to its ForkMesh account rather than trusting a display name supplied by a browser or repository host.
The publishing node signs the bounded snapshot with its registered account key. The Worker verifies that signature, the repository state, the publishing account, the time range, and replay order before activating a new ledger generation.
Public repositories only
Profile contributions are a public read model, so private repositories and their activity never appear in totals, daily cells, languages, or recent activity. A private or missing profile receives the same not-found response from the public endpoint.
Changing a repository from public to private removes it from the active public projection and invalidates affected profile periods. Deleting a repository or account also removes its contribution sources.
Snapshots do not publish raw author names or email addresses. They contain bounded daily totals, repository state bindings, coverage, and extension byte totals needed for the public card.
Mirrors and repository publications
Mirrors do not multiply contributions. ForkMesh groups mirrored copies into one logical project and selects the newest verified public source for that project, with a deterministic source key used to break equal-time ties.
A repository contribution is recorded once, on the first day the logical project is successfully published as public. Moving service between mirrors does not create another repository event.
The repository count shown in the profile header is the number of distinct current public logical projects owned by that profile. Contributions to another person's public project still count for the contributing profile when their signed identity is verified.
Languages
Languages describe current public default branches, not historical activity. ForkMesh totals supported source files by bytes and displays the five largest Languages plus an Other segment.
Unsupported extensions are grouped as Other only when they are eligible source files. Generated, binary, extensionless, oversized, and unreadable files do not invent a language.
Periods and Partial history
The default period is the trailing 365 UTC days. Historical controls request one full calendar year at a time, with an inclusive maximum of 366 days.
Complete means all required contribution dimensions are verified for the requested period. Partial history means verified data is available but an older period or source dimension is missing. Unavailable means no usable verified contribution source has been published yet.
Sparse dates are treated as exact zeros only inside verified coverage. Dates before the first verified day remain visibly unverified instead of being presented as inactive days.
When the live endpoint is temporarily unavailable, the profile may show the last successful result saved for that exact account and period. The card labels that result as saved data and provides a retry action.
Native by default
No README snippet, external image service, GitHub URL, or GitHub username is required. The desktop node publishes signed repository evidence during its normal catalog flow, and the ForkMesh profile loads one native contribution endpoint for the selected period.
Open your profile dashboard to see the skyline, activity mix, language footprint, exact totals, and recent public activity.