GitHub UI's Stale Contributor Count: A Cache Conundrum Impacting Engineering OKRs

When GitHub UI Disagrees with the API: A Contributor Count Conundrum

Accurate metrics are foundational for effective decision-making, especially when tracking progress towards engineering OKRs. A recent GitHub community discussion highlights a perplexing issue: the platform's UI displays stale and incorrect contributor data, directly contradicting its own API. This discrepancy not only creates confusion but can also undermine efforts to maintain precise performance dashboard software and accurate project oversight.

The Case of the Misleading Contributor Count

Marcel-Bich reported a significant bug affecting their repository's contributor page (Marcel-Bich/dogma). Despite the API correctly reporting two contributors, the GitHub UI persistently displayed four. This isn't just a minor visual glitch; it points to a deeper caching problem that resists standard troubleshooting.

API vs. UI: A Tale of Two Numbers

The core issue lies in the stark contrast between data served by the GitHub API and what's rendered in the web interface. Marcel-Bich provided clear evidence:

• GitHub API (Correct): A curl command to https://api.github.com/repos/Marcel-Bich/dogma/contributors accurately returned two contributors: "Marcel-Bich" (110 contributions) and "github-actions[bot]" (1 contribution).
• GitHub UI (Incorrect): The repository's web page displayed four contributors, a count that remained stubbornly wrong for days.

This inconsistency is frustrating for teams relying on GitHub for project visibility and engineering OKR tracking. When the API (source of truth) differs from visible data, it introduces doubt and extra verification, impacting developer productivity.

Extensive Troubleshooting, Limited Success

Marcel-Bich undertook an impressive array of troubleshooting steps, underscoring the bug's persistence:

• ✅ Verified local Git history, confirming two authors.
• ✅ Checked GitHub API, consistently returning two contributors.
• ✅ Force-pushed with rewritten history; verified no old branches/tags.
• ✅ Tested across multiple browsers/devices, and waited for cache expiration.

Despite comprehensive efforts, the UI remained unchanged, pointing strongly to a GitHub-side caching issue.

Evidence from the Command Line

The API responses clearly illustrate the discrepancy:

curl -s https://api.github.com/repos/Marcel-Bich/dogma/contributors?per_page=100 | jq '.[] | {login,contributions}'

Result:

{
  "login": "Marcel-Bich",
  "contributions": 110
}
{
  "login": "github-actions[bot]",
  "contributions": 1
}

The stats/contributors API endpoint, interestingly, returned an empty object, suggesting it might have been recomputing or affected by internal state.

curl -s https://api.github.com/repos/Marcel-Bich/dogma/stats/contributors | jq '.'

Result:

{}

GitHub's Response: Acknowledgment, Not Resolution

GitHub's official response was a standard acknowledgment that feedback had been submitted, offering no immediate solution. This highlights a common challenge in large platforms: resolving deeply rooted caching or data synchronization issues can be complex and time-consuming.

Impact on Developer Productivity and Engineering OKRs

The implications of such a bug extend beyond a simple incorrect number. For teams striving for transparency and accurate reporting, a misrepresentation of contributor count can:

• Skew Metrics: Incorrect data leads to misinterpretations of team activity or project health, directly affecting engineering OKR tracking.
• Reduce Credibility: A public-facing UI with incorrect data diminishes repository credibility.
• Hinder Recognition: Contributors might not be correctly recognized, impacting morale.
• Waste Time: Developers and managers may spend valuable time investigating discrepancies.

In an environment where tools like Blue Optima vs devActivity are compared for precise insights, the reliability of underlying data sources like GitHub is paramount. Accurate data is essential for any performance dashboard software to deliver meaningful insights.

Conclusion

Marcel-Bich's experience underscores a critical need for robust data consistency across all facets of a development platform. While APIs often serve as the ultimate source of truth, the UI is where most users interact. When these diverge, it creates friction and impacts the productivity and trust platforms like GitHub aim to foster. We hope GitHub addresses this caching bug swiftly to ensure contributor recognition and project metrics remain accurate and reliable.