I diagnosed the bug, wrote the fix, and posted the repro. Someone else PR'd my one-liner and got 100% of the credit. GitHub's credit model made that the rational move.

[xvdev09]

🏷️ Discussion Type

Product Feedback

Body

What happened, with timestamps

I filed unslothai/unsloth#6830: full root-cause analysis (int32 offset overflow in a
Triton kernel), a standalone reproduction that triggers the crash without downloading
the 700 GB model, and the exact one-line fix.

Three days later, PR unslothai/unsloth#6884 — opened by an account with zero prior
involvement in the issue — merged that same one-liner. The commit, the contribution
graph, and the auto-generated release notes credit one person. Not the one who did the
work. The timestamps are public and unambiguous.

Then it happened again, faster. On my second report (unslothai/unsloth#6831), a
different account paraphrased my own diagnosis back into the thread and opened a
competing PR 38 minutes later — racing against my own fix for my own bug.

This is not two coincidences. It is a workflow: watch issue trackers for reports that
contain ready-made fixes, convert them to PRs, harvest the credit. And here is the part
that should bother GitHub: neither account broke a single rule. The platform's
credit design makes farming diagnoses the rational strategy.

The design flaw

Every credit surface GitHub has — contribution graph, release notes, PR sidebar,
commit history — attributes a fix entirely to the PR author. The diagnosis, the
reproduction, the fix posted in the issue: worth exactly nothing, on every surface,
everywhere on the platform.

So the economics are: doing the hard part in public is a donation to whoever types
git commit fastest. The people hit hardest are exactly the ones GitHub says it wants
to grow — new contributors doing genuinely excellent debugging work, trying to build a
track record, discovering that the platform routes their work into other people's
reputations. The lesson it teaches them is brutal: never post a complete diagnosis
again.

To be clear about what I'm NOT asking: I don't want the individuals policed — they
played the board as designed. I don't want licenses changed — open source code is a
gift, that's the deal. Attribution is not ownership. The byline is the one thing that
was never supposed to be transferable.

The fix is cheap — the mechanics already exist

1. Surface linked-issue authors on merged PRs. A PR that merges with Fixes #X
   shows "Reported and diagnosed by @user" — exactly like co-authors are shown today.
2. Recognize Reported-by: / Diagnosed-by: commit trailers the way
   Co-authored-by: already works — including contribution-graph credit.
3. Include linked-issue authors in auto-generated release notes, which today
   credit only PR authors.
4. Count "authored an issue that a merged PR closed" as a contribution on the
   profile graph.

No moderation. No judgment calls. No new abuse surface. Every one of these reuses
plumbing GitHub already ships (Co-authored-by, linked issues, release-note
generation) — they just extend credit to the half of the work that currently doesn't
exist as far as the platform is concerned.

If this happened to you

Add your example below, with links and timestamps. Every farmed issue in this thread
is a data point that this isn't one person's bad week — it's what the incentive
structure produces at scale. Thread size is the evidence GitHub's product team can't
wave away.

Full technical writeup of the bugs in question: https://gist.github.com/xvdev09/c11362260fc7489847844c6919d66a54

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

[Hotaro26]

Hey @xvdev09,

First off, I just want to say—this is an incredibly well-documented and thoughtful post. Thank you for taking the time to write this all out. I can only imagine how frustrating it must be to put in the work to diagnose these gnarly bugs (especially that int32 overflow and the device context one—your write-ups are top-notch) only to have someone else swoop in and get the credit.

You're absolutely right that this feels like a systemic issue with how GitHub's credit system works. It's not about the code being "stolen"—as you said, open source is a gift—but about the attribution for the thinking and debugging work that goes into finding the fix. That's the part that can't be easily replaced, and right now, the platform doesn't reflect it.

Your suggestions are really practical and well-thought-out. I especially like the idea of surfacing "Reported-by:" and "Diagnosed-by:" trailers, and giving linked issue authors a spot in the release notes. It feels like a natural extension of the "Co-authored-by" system that already exists, and it would go a long way toward making the contribution graph tell a more complete story.

I also appreciate that you're not calling for pitchforks against the individuals—it's a valid point that they're just playing by the rules as they're written. The goal should be to change the game, not blame the players.

It's a bummer that this happened to you more than once, but posts like this are exactly how we start conversations that lead to real changes. I really hope the GitHub team sees this and takes it seriously, because the current system does risk discouraging the kind of deep, generous debugging work that makes open source thrive.

Anyway, just wanted to add my support and say thanks for sharing your experience and your proposed fixes. It's a valuable perspective, and you've articulated it really clearly. I'll be keeping an eye on this thread to see what others have to say.

Hope you have a better rest of your week!

[xvdev09]

Thanks a lot! Love to see someone who understands it.

[yatharthbhatt]

Heyy man !!!!!
I think the bigger problem isn't that someone else opened the PR—it's that GitHub has no way to represent different kinds of contributions.

Finding the root cause, building a minimal repro, and proposing the fix are all valuable work, even if someone else writes git commit first. Right now, those contributions disappear from every major credit surface (profile, contribution graph, release notes, etc.).

One thing I'd add is that maintainers should be able to explicitly attribute issue authors when merging a PR. Similar to Co-authored-by, something like Diagnosed-by or Reported-by could show up on the PR and release notes. That gives recognition without taking anything away from the person who implemented or merged the change.

The current incentives unintentionally encourage people to hold back detailed debugging until their PR is ready. That's probably the opposite of the collaborative behavior GitHub wants to promote.

[AhmadHassan-BTed]

Wow, much appreciated; Tracking down an int32 overflow in a Triton kernel is not a piece of cake. Writing the one-line fix takes five seconds. Watching that diagnostic work get farmed by a PR sniper just because GitHub's credit graph is obsessively tied to Git commits instead of actual problem-solving is pure madness.

You've already made the right move by logging this heavily documented case in the Product Feedback category. However, because GitHub's entire platform architecture treats the raw Git tree as the ultimate source of truth, changing how the contribution graph weighs non-commit actions is a massive structural shift that will likely take them a long time to implement.

Until GitHub natively adopts Diagnosed-by: trailers, the immediate defense relies on social engineering and project maintainers. To these, hurry up:

1. Drop a bold "I am currently drafting the PR for this, please do not open a competing one"* at the bottom of your root-cause analyses.
2. Lean on the maintainers; as a good maintainer who spots a copy-pasted fix from a zero-contribution account should intercept it. They can squash the merge and manually inject your GitHub email into a Co-authored-by: commit trailer so you get the graph credit you actually earned.

It is a broken incentive loop, but protecting your claims in the issue text is your best shield while the platform catches up.