How to Make a Reproducible GitHub Activity Snapshot

A GitHub activity comparison is useful only if another analyst can work out what you counted. A screenshot of a rising line leaves questions unanswered: which repositories, which window, which API, and which exclusions? A small evidence packet makes the observation easier to check without turning it into a claim about hiring, revenue or fundraising.

This workflow is for public repositories. It produces a dated activity snapshot, not an investment recommendation. Start with the site's methodology, then record your own collection choices explicitly. The site's exact repository aggregation should not be assumed from a manual pull.

Define the measurement before collecting#

Write a measurement contract in plain language. Include repository identifiers, the window start and end, timezone, endpoint, API version, and whether you are counting commits, pull requests or releases. Those are different objects and should have different columns.

Specify how an event on the boundary is handled. For example, choose a start-inclusive, end-exclusive interval. That is a proposed collection convention, not a claim about the site's implementation. Keep it unchanged between comparison periods.

Also decide what happens when data is missing. An unavailable response should remain unavailable. Do not substitute zero just to keep a chart continuous. A separate status field protects the numeric field from that mistake.

Keep the request reproducible#

GitHub's API versioning documentation explains the `X-GitHub-Api-Version` header. Record the version you requested rather than relying on a changing assumption about the default. Also keep the endpoint and non-secret query parameters.

Do not save access tokens in an evidence packet. Reproducibility needs the measurement recipe and permitted response data, not credentials. Record whether the request was authenticated and the access scope relevant to interpreting it, without including the secret itself.

A useful request record contains:

Collection time in UTC.

Repository owner and name as returned by the source.

Requested window and query parameters.

Endpoint and API version.

Response status and relevant cache metadata.

Any collection failure or incomplete pagination.

Separate source data from your calculation#

Keep the permitted raw response separate from your derived table. That makes it possible to fix a calculation without silently replacing the evidence used by the earlier version.

The repository statistics documentation describes the last year of commit activity grouped by week. The response contains `week`, `total` and `days`; the daily array starts on Sunday. If you add whole weekly totals to approximate a 14-day rolling window, disclose the bucket-boundary approximation. Do not label the result an exact rolling count.

GitHub also says repository statistics exclude merge commits, and contributor statistics exclude empty commits. A count from those endpoints therefore cannot be compared blindly with a count produced by another method. Write the exclusion rule next to the metric.

Capture pagination and cache state#

For a paginated endpoint, one successful page is not proof that the collection is complete. GitHub's pagination guide describes the `link` response header and its next-page links. Follow the links returned for the endpoint and record whether you reached the end. Do not treat a partial list as the complete population.

GitHub's best-practices guide describes conditional requests using an ETag or Last-Modified value. A `304 Not Modified` response means the requested representation has not changed. It is not a new empty dataset. Your record should point to the cached response that the check validated.

Keep request parameters stable when comparing cached representations. Changing filters or sort order changes what you requested, even if the endpoint name stays the same.

Review the packet before ranking#

Check that both periods use the same repository set and counting rules. If a repository was added, removed or moved, separate the coverage change from the activity change. A new denominator can move the result without telling you that the same observed team changed its behavior.

Use the trending view to find candidates for inspection, not to authenticate your collection. Multiple views of the same site data are not independent confirmations. The blog provides workflow context; your saved response and calculation remain the evidence for your particular observation.

A compact packet can contain a request log, raw responses, calculation notes, a derived table and a one-paragraph caveat. That is enough to explain why a name entered a watchlist and what would invalidate the comparison.