[Bug] (fight me) [Feature Request] Count original work in forks on contributor profiles

[ryan-winkler]

🏷️ Discussion Type

Bug / Bad Policy / Perception Bug, Overall Feature Request

Body

Title: Count original work in forks on contributor profiles

Bottom line

GitHub should count original work made in a fork on the contributor’s profile.

It should not count toward the upstream repository unless the upstream repository merges it.

The current problem

GitHub excludes commits, issues, pull requests, and discussions made in forks from profile contribution records.

For commits, the documented route to contribution credit is an upstream merge.

This combines two separate facts:

1. Whether upstream accepted the work.
2. Whether the contributor did the work.

Those are not the same thing.

Examples

A fork can become a real downstream project:

• A desktop edition can add installers, automatic updates, release pipelines, and operating-system integrations that do not belong in the upstream web application.
• A distribution fork can maintain packaging, compatibility, or security changes for its own users.
• A long-lived fork can follow a different roadmap while still taking useful updates from upstream.
• A company or community can maintain deployment-specific documentation and integrations that upstream does not need.

This work should not appear in the upstream repository’s contribution history unless it is merged.

It should still appear as work performed by the contributor in the fork.

The current incentive is backwards

A project can detach its fork relationship and become a standalone repository.

The work can then qualify for profile attribution even though the code, effort, authorship, and value did not change.

The only change was the removal of useful provenance.

GitHub should not require projects to hide their lineage to represent their contributors accurately.

Proposed model

GitHub should keep three records separate:

1. Upstream credit: only after the work reaches upstream.
2. Fork activity: activity that occurred in the fork.
3. Contributor credit: verified work performed by the user.

For commits, GitHub could:

• count only commits introduced in the fork;
• exclude inherited and synchronized upstream commits;
• require the fork’s default branch or gh-pages;
• deduplicate the same commit across the repository network;
• count the commit once if it later reaches upstream;
• show the fork and upstream relationship in the contribution details.

For issues, pull requests, and discussions, GitHub could count the repository-local activity on the user’s profile without adding it to upstream activity.

Expected result

Do not count downstream work as upstream work. Do count it as the downstream contributor’s work.

At minimum, if GitHub keeps the exclusion, profiles should disclose how much fork activity was removed from the displayed total and provide a fork-activity filter.

References

• [Profile contributions reference](https://docs.github.com/en/account-and-profile/reference/profile-contributions-reference)
• [Troubleshooting missing contributions](https://docs.github.com/en/account-and-profile/how-tos/contribution-settings/troubleshooting-missing-contributions)
• [Forks](https://docs.github.com/en/pull-requests/reference/forks)

Does this policy hide a material part of your work? Please add a concrete downstream example or an edge case that GitHub would need to handle.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐