Feature request: Make verified upstream repair contributions discoverable

[shin4141]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Other

Body

GitHub already records when contributors get fixes accepted by independent upstream maintainers. But that evidence remains difficult to discover and evaluate across repositories.

A person may successfully repair software maintained by OpenSSL, Microsoft, NIST, and other organizations, yet their profile primarily shows activity counts and generic achievements.

I propose an optional, evidence-linked Verified Upstream Repairs view that includes:

• Accepted fixes across independent repositories and organizations
• Links to PRs, commits, reviews, and releases
• Repair categories and verified technical outcomes
• Cross-project contributions without relying on stars or raw PR counts
• Machine-readable evidence for AI-assisted contributor discovery

This should not become a leaderboard that rewards PR volume or AI-generated noise.

The goal is to distinguish activity from demonstrated repairs, without claiming that GitHub guarantees an engineer's competence.

Contributors should not have to reconstruct their verified repair history manually in every README.

Better discoverability could help businesses find engineers who have demonstrated relevant repair abilities, and help OSS contributors turn their work into sustainable opportunities.

[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. ⭐

[KasraK2K]

Sharing what works today, plus where I think the gap in this proposal is genuinely real.

The data already exists and is queryable — the gap is presentation, not recording.

Search is the closest thing to a "verified upstream repairs" view right now. The key filter is excluding your own repos, which is exactly the "independent upstream maintainer" criterion:

is:pr author:USERNAME is:merged -user:USERNAME
is:pr author:USERNAME is:merged org:openssl
is:pr reviewed-by:USERNAME -user:USERNAME
is:pr author:USERNAME is:merged -user:USERNAME label:bug linked:issue

Machine-readable equivalents, which cover the AI-assisted discovery point:

• REST: GET /search/issues?q=is:pr+author:USERNAME+is:merged+-user:USERNAME&per_page=100
• GraphQL: user(login: "…") { contributionsCollection { pullRequestContributionsByRepository { repository { nameWithOwner owner { login } } contributions { totalCount } } } }

The only place an independent maintainer actually attests to a fix today is security advisory credits. When a maintainer publishes a repository advisory they credit contributors ("Remediation developer", "Reporter", and so on); accepted credits appear in the advisory and in the GitHub Advisory Database, and flow through to the CVE record. That is real third-party verification — but it only covers security fixes, which is precisely why this request still stands: there is no equivalent for correctness, performance, or reliability repairs.

Two suggestions for the proposal itself:

1. Frame it as an extension of advisory credits rather than a new profile tab. "Maintainer-attested fix credit" — opt-in on both sides, maintainer grants and contributor chooses to display — avoids the leaderboard failure mode by construction, because the signal comes from the maintainer's act of crediting rather than from a count. A volume metric can be gamed; an attestation cannot be self-issued.

2. "Verified" is already overloaded on GitHub (signed commits, verified domains, verified organizations). A view called "Verified Upstream Repairs" would read as a GitHub guarantee of competence, which is the exact claim the post says it does not want to make. Something like "Attested fixes" or "Credited repairs" keeps the meaning and the disclaimer aligned.

In the meantime the honest workaround is still a profile README — but linking the search queries above rather than a hand-maintained list, so it stays current without manual upkeep.

[shin4141]

Thanks — the search examples and advisory-credit analogy are useful. I agree that maintainer attestation is more meaningful than PR volume, and that “verified” could imply too much.

The value of an individual contribution is not the same question as the long-term sustainability of the contributor ecosystem. Small fixes can be valuable, but if capable contributors cannot afford to keep doing this work, OSS may lose experienced people and maintenance capacity over time. Better evidence of accepted repairs could help connect contributors with sustainable opportunities, provided it does not reward low-quality PR volume or add to maintainers’ review burden. I am not asking for every small fix to be paid.