Exploring Solutions to Tackle Low-Quality Contributions on GitHub · community · Discussion #185387

explore solutions to tackle this sort of low-effort spammy crap as well, maybe...

@patrickhlauke I'd also like to have a way to quickly block this type nonsense without having to build userscripts.
For real this is like "who's here in 2026" engagement bait and it should just be qualify as spam not upvoted over everything.
But the people upvoting are part of why so much spam exists too and i'd like to be able to block them all.

Another possible approach would be to define a set of rules or prompts and evaluate pull requests against them. PRs that don’t meet those rules could be automatically flagged or potentially even closed.

This is definitely something we’re exploring. One idea is to leverage a repository’s CONTRIBUTING.md file as a source of truth for project guidelines and then validate PRs against any defined rules.

In regards to AI-generated code, have you seen cases where the code is AI-generated but still high-quality and actually solves the problem? Or is it always just something you want to close out immediately? I'm curious if an AI-detection mechanism would rule out PRs where AI is used constructively, but interested in investigating this more and understanding what sensible would thresholds look like.

"AI-detection" is a backwards approach to a human problem filled with false positives.
Any system good enough to actually identify AI is a system that can be used to train undetectable AI and that would encourage MORE spam.
QED

The only actual test that ends up mattering is whether the code works and the contributor is allowed to contribute that code.
And that is the problem, code that doesn't work wasting humans time on slop.
The goal is less AI noise not more insisting on itself at every point in the maintainers life.

Judge work on its merits and its logic, no matter if the source is human, AI, or a combination thereof.

5. Produces a hash-chained evidence bundle - cryptographic proof of what was reviewed, when, and what the models found. Independently verifiable offline.

I think that for extra security you should make sure that this uses the blockchain distributed consensus model. Otherwise how do we know which proofs to trust?

Eager to hear the name of your new cryptocurrency.

I don't think it's a scam. I think it's a silly.

You are wading into a discussion which is primarily about harm being done by vibe coding.¹ So, uh... pushing a vibe coded project here is super ironic.

Damn, MF should hire you as their PM.

Deleting a PR would be a great feature, I've looked for this since before AI

@moraesc As the OP alludes to it's a legitimate flaw that all prior public issues become inaccessible if a public repository decides to disable issues going forward. Are you open to making changes to this? This discussion has been about a potential upcoming feature to disable PRs for a repository, but I want to explicitly ask if GitHub is open to considering improving the behavior for the existing disable-issues feature, too.

Thanks for sharing @Mossaka ! Great to get more feedback. This looks along the lines of what we've been hearing from maintainers too, so validates what some of the key pain points are. Were there any feature requests mentioned during the session?

Many of the badges can easily be gamed. I've seen plenty of users who've followed some blog post / YouTube video instructing them on how to gain badges in an automated manner through a provided script and pool of user / bot accounts.

Wow, that sucks!! I had no idea. I have never really chased the badges, just cracked a half-smile whenever I earn one from going about my day-to-day, but IMO they should be harder to obtain than this, especially with botting!!

Um...last I checked, labeling, assigning, and closing PRs are "write access" permissions. GitHub repo permissions are already very granular, in the places where such things are implemented. I don't think the proposal to include PRs in this is as big a lift as you're thinking it is.

They certainly are not, and I know this because I'm a member of an org where all org members have triage permissions, and only a dedicated mirroring bot has write permissions to push new commits to the repository. All org members must push to our in-house gitolite repository instead, and the reason for only handing out triage roles on GitHub is to prevent anyone from accidentally pushing to the wrong remote and causing the two to diverge (which would mean that GitHub gets force pushed, which would be disruptive to users).

Issues are disabled because we use bugzilla. PRs are allowed for the sake of users who don't wish to email patches to a mailing list.

I can:

• add various labels to PRs, such as the labels that cause our in-house CI system to bump a PR to the top of the queue.
• add assignees,
• add requests for reviewers,
• manage milestones (even if that particular repo doesn't use milestones),
• close them

I cannot:

• edit the PR title,
• edit or delete comments,
• approve workflows,
• mark my own review comment as needing action after the PR author responded to my review by saying "no" and clicking the "resolve" button (in my not so humble opinion, this is a grave usability flaw in GitHub PRs -- the author of a PR must not be permitted to win in a governance dispute with a project member, nor hide reviews by default in the hope that a different maintainer will not notice that the first maintainer has outstanding concerns)

The permission system in question is a toggle that allows administrators to select whether a user has read-only access, "triage", "write", or admin. I am entirely confused, what you seem to be calling triage that isn't what I just described. It is also funny to hear you describing permissions as ,"very granular" when it is a straight line going up at an angle and each level simply adds additional permissions on top of lower levels -- are you seriously suggesting that there's a GitHub repository role that "granularly" permits users to, for example, merge PRs but not add an assignee or a milestone?

Wow, that sucks!! I had no idea. I have never really chased the badges, just cracked a half-smile whenever I earn one from going about my day-to-day, but IMO they should be harder to obtain than this, especially with botting!!

Badges are something that GitHub implemented to copy Xbox games, are you really that surprised that they are vulnerable to cheating? :)

The literal definition of those badges is that you have e.g. "got X number of PRs merged", but you can get them by creating your own personal repo and submitting PRs to it, last I checked.

A badge that perhaps means a bit more is the one-off badges that you can get if you have had PRs merged by repositories whose code is in particular NASA missions, as you can't game that without knowing it will exist in advance, and the list of repositories whose code is used in some well known government-funded event is unlikely to include outright script-generated cheats.

I think the message was probably ineloquently phrased and comes from a misunderstanding of the term "write access [to code]", but the intent was probably to say that there's no particular reason that GitHub can't consider someone with a triage role also able to submit PRs even if disallowed from fully external folks?

But the triage role certainly is a mess and unsuitable for actually doing triage right now (not being able to edit titles or descriptions is crazy) and very far from granular for public free orgs (as opposed to enterprise orgs, I believe). That shouldn't have been a heavy lift to resolve either, but it has not been 😅

Giving repo owners the ability to "rate-limit" PRs from contributors is probably a good idea.

You can automate this today using on: pull_request_target GitHub Actions.

A lot of the solutions people have raised here are some form of "reputation system", which I find a bit uncomfortable because I think it will be wrong a lot of the time. And any rep system results in some people karma-farming.

I'm definitely open to the idea that we might incorporate some tools which give us signals about contributors. e.g., A comment bot that simply notes "warning signs" without forcibly closing would let us continue to exercise our judgement.

But before we discuss more here...

I have unsubscribed from this discussion and I recommend/urge anyone reading to not bother reading most of it, and potentially to unsubscribe as well. It started out somewhat-promising, but then the trolls came out to play.

The more limited maintainers community or per-project discussions are more usable, as there's less spam/junk.

We learn in physics that friction is good. AI has made PRs almost zero friction. Any solution means adding friction back. Thanks for the link to the "good egg" project. Very Bertie Wooster.

I'm definitely open to the idea that we might incorporate some tools
which give us signals about contributors.

The distinction you're drawing between "signal" and "verdict" is the
right one. A tool that surfaces warning signs without forcing a decision
keeps the maintainer in control — which matters a lot when the signal
is probabilistic, not deterministic.

The contributor-level signals you mentioned are useful, but I've found
PR-level signals more actionable for daily triage. Contributor history
tells you something about intent; PR signals tell you something about
the specific cost of reviewing this PR today.

The two that have surprised me most in practice:

Author engagement velocity: if a contributor opens a PR and doesn't
respond to any automated checks or comments within 48–72 hours, the
review cost goes up significantly — you're now doing the debugging for
them. Surfacing this early means you can reorder your queue before
you've invested time.

Scope/size mismatch: a PR that touches 12 files for a "minor fix"
is a flag regardless of who submitted it. Human or AI, the description
is wrong, and that means either the author doesn't understand the
change or they do and didn't explain it. Either way, it needs more
attention, not less.

Neither of these requires AI to compute. They're just signals that
get lost in a flat list view.

Yes, I understand and broadly agree with your sentiment - but without going into a long sidetrack into the ethics (and irony) of coding-LLMs actively undermining the very thing that even made them possible in the first place (open source code and contributors) ...I wanted to add a different voice with perhaps some more nuance,

In the sense that different tools can be applied to different jobs with different trade offs. Don't need a Ferrari to get to the grocery store, and all that - and if the tool can bring time back for actually fixing bugs or improving the product, working with well meaning contributors - I'm not as fussed with whether it incorporates AI or not, just as whether I don't mind much whether a tool is built in Python or C or Ruby if it works well relative to its costs/downsides.

Essentially heuristics defined in clear text rather than a classic deterministic scoring system. I don't think that would be that bad (and perhaps such things already exist) - and neither more or less impersonal as the bots in some OSS projects that nag you to sign CLAs; sign off commits; tell you when a merge conflict has appeared, close stale issues, respond and label based on PR templates /areas of code touched etc.

I will say, that I'm extremely opposed to bots in OSS projects that ''close stale issues" and I've never once seen it work out to the mutual satisfaction of both the maintainers and the community. Sometimes it doesn't even work out to the satisfaction of a single side -- e.g. a single developer forces through the bot and angers other developers.

CLA bots and signoff bots aren't heuristics based, any more than something like os.path.exists() uses heuristics to determine whether a file exists. People are attuned to treating such bots as expressions of inarguable fact.

I haven't actually seen bots that tell you when a merge conflict has occurred, although it's much the same (and effectively just serves as a notification pipeline for when the forge internal flag for displaying a merge conflict in the Web UI, changes status). It sounds incredibly painfully noisy and I would object to such a bot in projects I contribute to, but not because I think it's "impersonal", I just think it's far too prone to generating hundreds of new comments that anyone seeking to read the PR discussion will have to scroll through. Generating a new comment for a frequently changing status flag is not an effective communication channel; better would be a forge native feature to email the author when a merge conflict occurs, and then people can also see the summary at the bottom...

respond and label based on PR templates /areas of code touched

Labeling based on PR templates doesn't require a bot, last I checked. GitHub natively lets you associate templates with labels? Labeling based on paths modified in the diff is not really something I'd call a "heuristic" given it is a simple key/value mapping from paths to labels, manually defined in some script that is then reproducible and idempotent.

So none of this is really anything that I feel would map well to give a hint about how users might respond to a heuristics based LLM review tool.

Especially keep in mind that people who don't like LLMs (such as me) will absolutely flip out any time such a tool erroneously gives them a failing grade and "penalizes" them. And a review tool that doesn't do anything to hide PRs with a failing grade from developer attention, does not accomplish anything to solve the problem of developers being forced to expend their attention on what they consider spam.

and if all comments added have an appropriate disclaimer/disclosure and ability for a contributor to "get help" with a bit of friction if it goes awry - that could perhaps be a useful piece of the toolkit?

A disclaimer/disclosure will do nothing because the victim knows that the project chose to impersonally:

• act without knowledge,
• use the tool that they said is bad, to leap to the incorrect conclusion that the victim is using the exact same tool and penalize them in some manner for using it

An appeal button will not help because people have a natural aversion to challenging authority and this goes quadruple for cases where a first time contributor feels slighted and "on the defensive" from the initial interaction and doesn't have some motivation to get the change in "at all costs and no matter what I have to swallow to do it" (such as a critical work-blocking bug that cannot be worked around in a dependency that cannot be replaced or reimplemented).

I will say, that I'm extremely opposed to bots in OSS projects that ''close stale issues" and I've never once seen it work out to the mutual satisfaction of both the maintainers and the community.

There is currently at least one running example of this problem anthropics/claude-code#16497

Yes, I am mainly referring to heuristics where a bot (AI or otherwise) tries to use various aspects of a contribution and the contributor's history to assess signal vs noise for a contribution - not existing deterministic bots doing simple automation, or "rules" for contributions.

I'm aware templates can be used for labels, but some projects use heuristic based bots for this (e.g grpc, many others) depending on how they use labels.

I wasn't making any particular judgment on the merit of all these various bots, nor claiming that an AI agent should be the only tool available - just highlighting that there are many things you might want to do in terms of automation, but they all require setup and configuration, and in some cases exposing your project to supply chain risk for that bot due to the privileges they run with.

If people want to block all AI contributions they should be able to do so, sure, but existing contribution prioritisation is opaque for the vast majority of open source projects anyway, so a signal visible only to maintainers is no worse than the current situation of opacity.

I'm in no way claiming that this could be suitable for all projects - no tool (AI or otherwise) would be.

That assumes you have the resources to evaluate every contribution to determine if it is something you don't need/want.

AHAHAHAAHAHAAH haha ahuehue heu omg I can't.
That's literally the point of this entire discussion, NOT having the resources.

Humans don't have infinite time, and LLM's do NOT have infinite energy resources.
Even if you are the type to let AI go at full rip you will burn time somewhere in some sort of review, backfilling, or defending against security breaches etc etc etc ad nauseum; all the while turing your time into a free training vector for other businesses software.

Productivity gains cannot be infinite in a mortal world using probability distributions.
We need deterministic tools for human to human contribution.
Yeeeesh.

One concern I have with repo-level PR restrictions is that they may disproportionately impact first-time contributors who do want to engage meaningfully but don’t yet have collaborator status.

Completely agree with this concern and just want to emphasize that this is just a starting point and not the final solution. The plan is to develop more tools and frameworks for both maintainers and contributors to help address the "slop" problem.

Personally, I think the most promising direction here is criteria-based PR gating rather than blanket restrictions things like required checklist completion, passing CI, linked issues, or acknowledgement of contribution guidelines before a PR can be opened.

Some other ideas we're exploring are requiring an issue to be created first before a user can open a PR or leveraging AI to validate a PR against rules defined in a CONTRIBUTING.md file or something similar. Any thoughts on that?

Some other ideas we're exploring are requiring an issue to be created first before a user can open a PR

Requiring that an issue be assigned to the user before they can post a PR would work well with our process. We already request that users who open a PR also open an issue so it can be triaged into the appropriate milestone. It would be great if GitHub had a way to normalize that workflow.

I like the idea of "issue first".
Allow PRs

• either from project members
• or for existing issues that the maintainer manually put in some kind of "expecting PR" state.

Potentially make the order irrelevant. Have PRs from non-members in some kind of "hold" state, until the issue has been opened and accepted. Close PRs that link to rejected issues. Auto-close PRs in "hold" state from non-members that do not link to an issue after a configurable period.

One concern I have with repo-level PR restrictions is that they may disproportionately impact first-time contributors who do want to engage meaningfully but don’t yet have collaborator status.

Completely agree with this concern and just want to emphasize that this is just a starting point and not the final solution. The plan is to develop more tools and frameworks for both maintainers and contributors to help address the "slop" problem.

Personally, I think the most promising direction here is criteria-based PR gating rather than blanket restrictions things like required checklist completion, passing CI, linked issues, or acknowledgement of contribution guidelines before a PR can be opened.

Some other ideas we're exploring are requiring an issue to be created first before a user can open a PR or leveraging AI to validate a PR against rules defined in a CONTRIBUTING.md file or something similar. Any thoughts on that?

I think leveraging AI to validate PRs against CONTRIBUTING.md rules is promising, but only if it’s deterministic in enforcement. If the output is advisory rather than blocking, maintainers still carry the review burden.

One concern I have with repo-level PR restrictions is that they may disproportionately impact first-time contributors who do want to engage meaningfully but don’t yet have collaborator status.

Completely agree with this concern and just want to emphasize that this is just a starting point and not the final solution. The plan is to develop more tools and frameworks for both maintainers and contributors to help address the "slop" problem.

Personally, I think the most promising direction here is criteria-based PR gating rather than blanket restrictions things like required checklist completion, passing CI, linked issues, or acknowledgement of contribution guidelines before a PR can be opened.

Some other ideas we're exploring are requiring an issue to be created first before a user can open a PR or leveraging AI to validate a PR against rules defined in a CONTRIBUTING.md file or something similar. Any thoughts on that?

I think leveraging AI to validate PRs against CONTRIBUTING.md rules is promising, but only if it’s deterministic in enforcement. If the output is advisory rather than blocking, maintainers still carry the review burden.

@jamietanna does the discussion-first approach that you follow require all users to create a discussion first, or only "non-collaborators" (users without write access) ?

@moraesc generally non-collaborators. The maintainers and collaborators are able to create an Issue and remove the needs-discussion label that auto-closed an Issue raised by a non-collaborator

That being said, non-collaborators will often go through the Discussion process, as it's pretty good at distilling what we want, and a place to work through ideas before they're in an Issue

The issue with this approach is that pretty much any popular project would already have enough of pre-existing issues/discussions to choose from.

In our case, we've noticed that a good chunk of AI slop was targeting old issues with the "good-first-issue" label. - They're attractive in a sense that, by definition, it's not something complex to do, so you don't have to spend much time prompting AI and, thus, can generate dozens or even hundreds of PRs a month (we've seen such accounts) across a random list of popular repositories (automated tooling makes it easy to find a target). We ended up removing the label from all issues.

Agree but the permissions names might need a different messaging:

So when an unprivileged

Try this optics nit on for size:
"The unprivileged cannot code on github. ; unless their AI is good enough to pass."
Only being partially sarcastic in order highlight while less privilege from a security standpoint is 100% valid there are some very real problems in how we phrase permissions with AI in the mix reallllly muddying things more and more while also wanting/needing new people to join in.

There is non-zero chance for this slop problem to grow into an economic/cultural divide in haves good AI's vs have no-AI's.
Making under-privelaged excuse for some odd twisted ladder pulling on a "social coding" platform; that could weirdly encourage more AI use by any possible contributor just so they can escalate privilege's making the actual learning seem more and more less useful.
Instead of security/spam prevention tools for maintainers to vet new contributors who do want to learn but can no longer afford the entry fee.
ugh 🤮 .

This is crazy. The "AI" bots are now attacking "AI" (look at this account further, it has made a good point, but the username is jingchang0623-crypto, the handle is "AIWalker" and 5 of its 6 most popular repositories are "AI" related, 5 of them being about OpenClaw. (I use "AI" in quotes, as I feel "Artificial Intelligence" is a buzzword. There is no actual intelligence here, just something mimicking intelligence)

Also none of their points actually make actual sense lol.

@seanpm2001 criticises nickname @jingchang0623-crypto

@JC5 point lack of sense but for me is unclear what is hard to understand in this thoughtful sharing of own experiences as @seanpm2001 already mention after insightful looking into full record of @jingchang0623-crypto backstory

for me this is the reason why people don't want to work with other people

WTF did I just read, this makes absolutely no sense. Did you ask AI to generate some of the slop in there?

And without genAI, people could not just scatterblast slop across many repos with miniscule effort on their own side.

finally someone responses - @ThiefMaster

i'm trying to get the reason why only anger is visible without reasoning behind reactions

I think that your assumption that I without any doubt have to talk with AI before I talk with humans shows your lack of sympathy toward users of any kind of AI

BTW congrats for being honored with Mars2020contrib badge

The problem for me personally is way worse than I assumed. I knew it was bad, but not the 50+ PRs spanning 15 years and 20+ repos :O

I built a helper recently that lets me prioritize PRs for review: https://github.com/jaegertracing/maintainer-tools. The list is first sorted by repo because I only look at 3 of them, but it's easy to change to render differently.

npm run triage
# → writes ./triage.html
open triage.html

@yurishkuro I am so installing this first thing tomorrow morning (Colombia time)!

The cross-repo triage problem is brutal at that scale. Your script output
actually illustrates the core issue well — mixed repos, mixed staleness,
PRs from 2023 sitting next to ones from last week, no way to know at a
glance which ones need attention today.

The thing I've found missing from most list-based approaches (including
ones I've tried) is context about why a PR should be prioritized, not
just when it was opened. A 2023 PR with a bot dependency bump is a
different problem than a 2023 PR from a contributor who's still actively
responding.

A few signals that have changed how I work through queues like this:

• Whether the author has commented in the last 7 days (live vs. dead PR)
• Whether CI was passing at the time the PR was opened, not just now
• Whether the files touched overlap with anything else currently open

The last one is the most underrated — two PRs touching the same files
are not independent review decisions, even if they look unrelated.

@yurishkuro's maintainer-tools approach of rendering to HTML is smart
for the overview layer. The piece I'd add is a priority signal per PR
so you're not just seeing the list but knowing where to start.

The priority is indirectly built into how this report organizes the output, but priority is not a single dimension, so the report is focused on classification rather than a straight ranking.