Exploring Solutions to Tackle Low-Quality Contributions on GitHub

[moraesc]

Hey everyone,

I wanted to provide an update on a critical issue affecting the open source community: the increasing volume of low-quality contributions that is creating significant operational challenges for maintainers.

We’ve been hearing from you that you’re dedicating substantial time to reviewing contributions that do not meet project quality standards for a number of reasons - they fail to follow project guidelines, are frequently abandoned shortly after submission, and are often AI-generated. As AI continues to reshape software development workflows and the nature of open source collaboration, I want you to know that we are actively investigating this problem and developing both immediate and longer-term strategic solutions.

What we're exploring

We’ve spent time reviewing feedback from community members, working directly with maintainers to explore various solutions, and looking through open source repositories to understand the nature of these contributions. Below is an overview of the solutions we’re currently evaluating.

Short-term solutions:

• Configurable pull request permissions - This has been a long-standing request (since 2016) and is a first step in giving maintainers more tools to customize their PR experience. Repository owners will be able to control pull request access at a more granular level by restricting contributions to collaborators only or disabling PRs for specific use cases like mirror repositories. This also eliminates the need for custom automations that various open source projects are building to manage contributions.
• The ability to delete a PR from the UI - This provides maintainers with the ability to remove spam or low-quality PRs directly from the interface to improve repository organization.

Long-term direction:

As AI adoption accelerates, we recognize the need to proactively address how it can potentially transform both contributor and maintainer workflows. We are exploring:

• Enhanced permission models - Provide maintainers with more tools so they can customize their PR experience:
  • More granular controls for determining who can create and reviewing PRs beyond blocking all users or restricting to collaborators only.
  • Ways for maintainers to define criteria that PRs must meet before they can be opened.
• Improved triage tools - Potentially leveraging AI to evaluate contributions against project guidelines and standards to identify which contributions maintainers should focus on reviewing.
• Transparency in AI-assisted contributions - Improved visibility and attribution when AI tools are used throughout the PR lifecycle.

Next Steps

These are some starting points, and we’re continuing to explore both immediate improvements and long-term solutions. Please share your feedback, questions, or concerns in this thread. Your input is crucial to making sure we’re building the right things and tackling this challenge effectively. As always, thank you for being part of this conversation. Looking forward to hearing your thoughts and working together to address this problem.

[xavidop]

such a great intiative

[SunShineHead]

To to lessen the complain of clients using the app itself and minimize the log in ratio from 43 different person per account to at least 22 clients may have their own privacy in using the app itself it is awesome for not knowing that everything was being tracked behind the scene, i'm starting to get curious about the tracking issues as thought it's with your games.

[patrickhlauke]

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

[PaulNewton]

@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.

[xavidop]

I know this is a pretty ambitious idea and not trivial to implement, but it would be really powerful to have an AI-detection mechanism with a configurable threshold at the repository or organization level. That way, teams could decide what percentage of AI-generated code is acceptable in pull requests.

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.

[moraesc]

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.

[PaulNewton]

"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.

[who]

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

[xavidop]

As of today, I would say that 1 out of 10 PRs created with AI is legitimate and meets the standards required to open that PR. On 28 Jan 2026, at 18:41, Camilla Moraes ***@***.***> wrote:  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 genuinely solves the problem? Or is it alwaays just something you want to close out immediately? I'm curious because I'm wondering if an AI-detection mechanism would rule out PRs where AI is used constructively, but that's where we'd want to test this thoroughly and understand what sensible thresholds look like. — Reply to this email directly, view it on GitHub<#185387 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABBWEYEKF6WLNDKE376L3GD4JDYFXAVCNFSM6AAAAACS7B7C7OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNRTGEZTMMI>. You are receiving this because you commented.Message ID: ***@***.***>

[eli-schwartz]

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.

[sirosen]

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.

Footnotes

1. In the El Reg article about this discussion, a GitHub manager said that this isn't about LLMs, which is so patently dishonest that it's offensive. ↩

[bxb100]

Damn, MF should hire you as their PM.

[tsjensen]

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

[rmacklin]

@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.

[Mossaka]

Hey! I am from Azure Core Upstream and we have a lot of OSS maintainers who mainly maintain repositories on GitHub. We held an internal session to talk about copilot and there is a discussion on the topic where maintainers feel caught between today’s required review rigor (line-by-line understanding for anything shipped) and a future where agentic / AI-generated code makes that model increasingly unsustainable.

below are some key maintainer's pain points:

1. Review trust model is broken: reviewers can no longer assume authors understand or wrote the code they submit.
2. AI-generated PRs can look structurally “fine” but be logically wrong, unsafe, or interact with systems the reviewer doesn’t fully know.
3. Line-by-line review is still mandatory for shipped code, but does not scale with large AI-assisted or agentic PRs.
4. Maintainers are uncomfortable approving PRs they don’t fully understand, yet AI makes it easy to submit large changes without deep understanding.
5. Increased cognitive load: reviewers must now evaluate both the code and whether the author understands it.
6. Review burden is higher than pre-AI, not lower.

[moraesc]

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?

[Tibor17]

1. I have a problem with the following statement. It is very leftish. The GitHub has no rights to impose such limitations. You have to configure your repo and TTL of a PR:
   limited timeframe to delete a PR. Maybe a week in case of low activity

2. Regarding the next statement, you can delete a PR when you close it. How different is close and delete?
   Next question, why you mentioned low-quality PRs? I hope you do not want to employ AI to determine what low quality means! We, maintainers, have to determine it.
   The ability to delete a PR from the UI - This provides maintainers with the ability to remove spam or low-quality PRs directly from the interface to improve repository organization.

3. Who is an external contributor?
   Example, you mean a situation when XLibre developers are removed from Xorg?
   Restrict PRs to collaborators - This provides more granular access control, allowing contributions exclusively from existing collaborators while blocking external contributors.

4. This would segregate the maintainers and we don't want it. We have flags on the PRs to indicate what to do with them.
   If the AI is leveraged to this job, we have segregated the maintainers again in the Open Source. But the rule is that we are all equal, and this might be a problem if one is notified and the second guy is not. You may not totally trust the AI due to finally the result may change without the second guy or the quality would be bad without his opinion since he does not attend the review.
   Improved triage tools - Potentially leveraging AI to evaluate contributions against project guidelines and standards to identify which contributions maintainers should focus on reviewing.

[AlanGreene]

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.

[jamisonbryant]

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!!

[eli-schwartz]

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?

[eli-schwartz]

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.

[chadlwilson]

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 😅

[sirosen]

An option to limit new contributors to one open PR would be nice.

Just today I had to batch-close several AI generated PRs which were all submitted around the same time.

For this protection, defining "new contributor" is probably not possible to do perfectly. But anyone who has no interactions with a project prior to the last 48 hours seems like a good heuristic. The point is to catch such a user at submission time and limit the amount of maintainer attention they can take up.

For a different type of problem, I'd like to be able to close PRs as "abandoned", similar to the issue close statuses. It's a clear UI signal to the contributor that their work isn't being rejected but I'm not going to finish it for them. Several of the low quality contributions I have handled, dating back to before the Slop Era but getting worse, are simply incomplete and need follow through.

[sirosen]

And what counts as an interaction, random comments?, a catch-22 PR they can't submit without previously submitting another PR?, an #intros discussion thread buried somewhere... etc etc

I was saying that I would like to be able to limit new contributors to 1 open PR. The problem -- as stated -- is that a single user can hammer a project with 5-10 PRs and there's no interaction limit to keep them from doing that.

Being able to say "hey, before you have a merged PR, we only allow you to open 1 PR" reduces the amount of manual cleanup we need to handle.

Is more UI doodads the solve here,
Isn't marking PR's closed abandoned not already a solved problem by closing the PR, applying labels, comment on the PR, or title edits, etc ?

"The solve" makes it sound like there's some singular solution here. I don't think there is.

I try to communicate very clearly with contributors, especially when rejecting their work (or "work").

It takes time and energy to explain why things are being closed. If I could delegate part of that effort to a close-status, I would find it helpful. If you have a well indexed library of response templates, that's another way to make it easier.

Is it the solution to slop? Obviously not. That would be a pretty ridiculous position to hold.

A theme of alot of these posts seem to be of the "must be this tall" variety which seems more like a platform ranking system than just being able to turn off or gate PRs.

I was intentional about phrasing my idea as something which would turn down the volume on interactions with new contributors without forbidding them entirely.

"You haven't contributed to this project before and now you are filling 30 PRs" is not a likely usage mode for a normal human on GitHub. If you open your 5th PR and there aren't even comments on your other 4, it's a near certainty that something is wrong.

I don't see how wanting a protection against this form of abuse is even remotely similar to a reputation/ranking system.

[who]

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.

[webknjaz]

@sirosen look what I've just found: https://github.com/marketplace/actions/good-egg-trust-scoring-prs. Not sure it'd score me very high (saying hi to corner cases 😃) but I'm seriously considering trying it out. The methodology there reminds me of what my ML friend @LukaIhn was suggesting in our chats strategy-wise.

[sirosen]

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.

[timrichardson]

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.

[dgoldman0]

For the long term horizon: Implement a reviewer LLM that first does an initial scoring of the PRs? Critique is far easier than creation of a correct result. That automated pre-moderation should give the edge needed to handle. Depending on whether you just use rich prompting or fine-tuning, you can even start building an "oracle vox" for your project, which acts as a reasonably informed, reasonably on point virtual representative for the project/organization.

[chadlwilson]

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.

[eli-schwartz]

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).

[marcindulak]

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

[chadlwilson]

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.

[PaulNewton]

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.

[PraiseTechzw]

This is a very real problem, and I appreciate that it’s being treated as systemic rather than blaming maintainers or contributors individually.

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.

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.

On AI usage specifically, transparency feels more scalable than prohibition. Clear disclosure combined with automated guideline checks could help maintainers focus on high-intent contributions without discouraging responsible AI-assisted workflows.

Looking forward to seeing how these ideas evolve especially solutions that preserve openness while respecting maintainer time.

[moraesc]

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?

[robmen]

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.

[taranion]

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.

[PraiseTechzw]

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.

[PraiseTechzw]

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.

[funnelfiasco]

Thinking along the lines of the discussion first approach that Ghostty uses, I think one way to create just enough friction would be to have an opt-in where a PR has to be linked to an open issue or discussion topic. So when an unprivileged (i.e. does not have elevated privileges on the repo) user tries to create a PR, there's a required field that takes an issue/discussion number. If that's not provided (or the corresponding issue/discussion is closed), then the PR can't be created.

This could be trivially worked around by throwing in any old issue/discussion (or by creating one), but it may cause just enough friction to help. To guard against this, perhaps maintainers could set a "minimum age" for the issue/discussion (e.g. 12 hours) to prevent creating fake issues to support a spammy PR.

[moraesc]

@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) ?

[jamietanna]

@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

[marcindulak]

The problem with github discussions is that they are isolated - they don't automatically create links https://github.com/orgs/community/discussions/2971 like issues do, meaning information is scattered in two places and difficult to find.

[weisdd]

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.

[PaulNewton]

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 🤮 .

[tomasz-tomczyk]

I started https://llmwelcome.dev/ to flip the topic and be explicit about GH issues where maintainers wouldn't mind LLM input on.

Tag issues with llm welcome label, make it opt-in by the maintainers - then they get surfaced in the directory (similar to goodfirstissue.dev, but for LLM).

If someone's going to spend tokens, at least make it opt-in and explicit. Otherwise I'd recommend automatically closing with a GitHub action like anti-slop (not mine).

[MikeMcC399]

Open source repo maintainers / owners are now challenged to describe acceptable use of AI in their CONTRIBUTING instructions.

Perhaps GitHub could suggest template text?

This could maybe also mirror the additional settings / described in https://github.blog/open-source/maintainers/welcome-to-the-eternal-september-of-open-source-heres-what-we-plan-to-do-for-maintainers/

Here are a couple of examples:

• https://github.com/tldraw/tldraw/blob/main/CONTRIBUTING.md (no external contributors due to AI Contributions policy tldraw/tldraw#7695)
• https://fastapi.tiangolo.com/contributing/#automated-code-and-ai (use AI with caution)
• https://github.com/openclaw/openclaw/blob/main/CONTRIBUTING.md#aivibe-coded-prs-welcome- (AI encouraged)

[MikeMcC399]

This would be the manual form of describing what could also be put in an AGENTS.md instructions / conventions document for automatic use by AI.

[thebentern]

I would like to see regex based moderation tools added to the organization and repo level. I find that a lot of the low-effort LLM generated PRs share patterns of text that could be categorized and acted upon in a number of different ways, from adding an appropriate label to automatically closing. Some of this can be probably done with agents, but IMO that is a waste of resources when simpler tools like regex matching will do the trick.

[PaulNewton]

How isn't this already solved with workflow automations?

[yigalirani]

How about charging people to post PR? This would deter low effort AI generated posts and add an income stream to the maintainers. maintainers have the option to revert the charge.

[PaulNewton]

Can't that be done with a private repo, using a public repo as the onboarding

[aantti]

Hey, appreciate this one :) Aside from the actual description in PR and issues - and as some people already mentioned - it would be useful to have more control over the "AI slop" in comments (in PRs, issues, but increasingly so - in Discussions). We've started to see more automated comments popping up that don't add value, but seem meaningful at a quick glance, while they aren't. People use it for self-promotion, or even promoting the company/product.

[aadaam]

Well, maybe agents should respect CONTRIBUTING.md more?

At the end of the day, this is not a human issue: this is a prompt engineering issue.

When asked to contribute to a repo, Claude Code should run a "contribution subagent" whose sole job is to ensure it matches contribution guidelines.

IF we want to do it on the repo side, I don't think it should be on the budget of the often monetary constrained OSS projects: I do understand that essentially the same subagent can be run as a github action on all PRs ad well, but I believe it is better if it goes from the token budget of the contributor, rather than the receiver.

Perhaps a kind of signature system (perhaps blockhain-based?) should be used to ensure that such an agentic check has indeed been run with the right level of model.

Very-very soon over 90% of code will be AI assisted. It's time we prepare for those times and not ask in "checkboxes" whether the contribution is from the remaining 10%.

[MikeMcC399]

This is perhaps an area where GitHub could help standardize on a file such as AGENTS.md that could instruct AI if it should be working in a repo and under what contraints?

[aadaam]

@MikeMcC399 I believe in certain repositories, MOST contributions will come AI assisted.

Of course, CLAUDE.md / AGENTS.md should be respected, but I believe we already have CONTRIBUTING.md as a quasi-standard practice.

It's relatively easy to expect main vendors to make sure they train their models on respecting that, and also main devtools (claude code, codex, cursor, antigravity, windsurf) to release default skills / subagents / rules dealing with it.

Once that's done, quality check will be built into the AI-based contribution workflow and the AIs responsible for the "slop" will ensure themselves that they meet quality standards.

I trust most contributors mean no harm, they just have a low understanding on how to properly contribute.

[PaulNewton]

It's bad practice to assume good faith on the part of spammers or those ignorant in their usage of spam tools creating spam.

this is a prompt engineering issue.

and this is uncooked pie in the hallucinated sky ideation, keep cooking.
Your ultimately engaging in mudding things trying to shuffle responsibilities to ambiguous upstream sources while the problem continues TODAY in this place.
Like a flood coming for a bridge as several dams have broken, everyone is trying to solve the problem of getting people off the bridge.
But for some reason your talking about building a bunch of different dams while your standing on the bridge right now.

Claude Code should

Sir, this is a github.com, claude is over here: github.com/anthropics/claude-code & claude.com/product/claude-code

maybe agents should respect

maybe, respect this is a zero trust problem don't waffle words against those selling spam-shovels built on the mountains of disrespect.
While the disrespect is actively happening.

Yeeesh,
Beyond repos at the platform it becomes a TOS problem for github-apps to not facilitate spam; apps == LLM providers.
But if you think for a moment github would stop that money flowing.. lololol good luck with that.
and .. blockchain like what you think providers would burn that money willingly

[eli-schwartz]

Very-very soon over 90% of code will be AI assisted. It's time we prepare for those times and not ask in "checkboxes" whether the contribution is from the remaining 10%.

Please respect the fact that ACTUAL FOSS MAINTAINERS consider this to be:

• a lie
  • ... which is toxic to FOSS
• an assertion made without evidence

People who continually say "very soon over 90% of code will be AI assisted" are attempting to move the overton window and normalize the idea to the people who think it's trash.

I reject your false claims. "Studies show" -- okay, and the other studies show developers don't like when their bosses FORCE them to use LLMs, won't use them unless forced to on threat of being fired, and say using them makes them less productive.

Besides which, the idea that "everyone does it, so we should too even if we think it is bad" is simply... intellectually dishonest. It would be honest, to change one's mind and decide it is actually good. To persist in thinking something is bad but still use it "because others do, so I have to get with the times" would be dishonest and a sign of low moral character. Why would anyone with self-respect try to ruin their own respect for themselves as a person, the way you suggest?

[davidmax5120-crypto]

yes

…

On Sat, Feb 21, 2026 at 8:40 PM Waldir Pimenta ***@***.***> wrote: Great points! I agree that this discussion needs to focus less on restricting the input by contributors and more on how to help communities grow so that there is more capacity to handle the input in the maintainers' side. In fact, this "walls" metaphor leads to a related point: there should not be a binary distinction between "us" (maintainers) and "them" (contributors), but rather a gradient-like spectrum. Contributors should have a clear path to becoming gradually more trusted within a project, and gradually getting more responsibilities and ability to moderate aspects of the project. Perhaps something similar to StackExchange sites, which can specify their own thresholds of what reputation levels allow which kinds of actions, would be an interesting tool that GitHub could offer communities to configure. — Reply to this email directly, view it on GitHub <#185387 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B32TNB5NU34JPQ5EGRPW6AT4NC7EFAVCNFSM6AAAAACS7B7C7OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOBYGQ2DQNA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[patrickhlauke]

this is exactly the sort of thing i keep seeing in my repos...pointless comments and issues by new accounts with clearly generated usernames... (something1234-word)

if we could tackle this sort of crap, that would already help...

[nickserv]

I appreciate the irony.

[StefanieSenger]

I have just participated on the GitHub community survey for project maintainers. My answer for the only free text field
"Is there one feature you would love to see changed or introduced to the GitHub experience? If so, why?" was:

I'd like to have a setting on the project to limit new contributions to 5 (or so) per account until 
project maintainers explicitly allow them to open new PRs. (A probation period.)

I'd like to have a human-verified (only human beings with verified accounts can vote) scoring 
system for the quality of work a user brings if they are involved in open source projects 
(that are not their own projects).

I'd like to reliably see if a contributor has used AI on a PR and ideally (I know, hard to do) 
how much time they spend self-reviewing a potentially generated PR, and which tool they used.

To give people ideas what to ask for.

[nityah-dev]

One safeguard I think projects could consider is maintaining a human‑verified baseline snapshot of the repository. Tag and preserve a version of the codebase that predates AI‑generated contributions (is this simple to do now?), and mark it clearly as a “clean, trusted human baseline.” If future AI submissions introduce licensing risks, security flaws, or reputational issues, maintainers would have a clean restore point to roll back to.

This will give legal protection by showing a human‑verified state of the project exists. And also guarantees that maintainers always have a safe fallback. This won't replace detection or contribution filters, but will complement them. Even if AI contributions slip through, the project has a resilient safety net. Would love to hear thoughts on whether GitHub could support this with tooling (e.g., tagging, branch protection, or automated “baseline snapshots”) so projects don’t have to manage it manually.

I am not saying all AI submissions are bad, or all human ones are good. But it helps to know we have a version built by humans and approved by humans.

[PaulNewton]

mark it clearly as a “clean, trusted human baseline.”
Already done through contributor agreement automations.

The rest of it is just called a backup, commit history, or a fork, or a private repo, or at worst a branch etc etc.

Otherwise your introducing a problem in way more complexity in the project.
And serious issues in some part of the code base, such as branches, always being out of sync and endless commit conflicts.
Repo X
-> commit 1 human contribution
--> commit 2 AI slop
---> commit 3 human contribution -> merged to main
There is no clean version of the codebase now, unless you commit#3 onto commit#1 skipping ALL the changes that were made in commit#2 and dealing with that MESS.

How do you even ship the software at that point.
With current practices you get main & dev & feature-branches
If you add some offshoot "aislop" branch that isn't an addition problem of a 4th branch it's multiplication problem of EVERY other branch needing an offshoot.

*edit fixed commit logic and to prevent auto-linking to issues

[Gecko51]

This is a really thoughtful proposal and a very practical approach to a growing concern in the open-source community. Treating AI contributions with a "defense-in-depth" mindset is definitely the right way to go.

To answer your questio, is this simple to do now? Yes, on a manual level, it is straightforward. Maintainers can currently achieve this by creating an annotated Git tag (e.g., v1.0-human-baseline) and utilizing GitHub’s tag protection rules to ensure that specific snapshot can never be overwritten or deleted.

However, your point about native GitHub tooling is spot on. If GitHub formalized this, it would be incredibly valuable. Here are a few thoughts on how this works in reality and where tooling could help:

Native Badging & Locking: Instead of just a standard Git tag, GitHub could introduce a dedicated "Verified Baseline" state. This could lock a specific commit in time with a UI badge, making it legally and visually clear to users and auditors what the last fully human-vetted state was.

The Rollback Reality (The "Nuclear" Option): While having a fallback is great for peace of mind, actually rolling back to a baseline from months ago means throwing away all subsequent work, both the bad AI code and the good human code.

The Blurry Line of Authorship: The hardest part of maintaining this baseline moving forward is that the line between "human" and "AI" is already disappearing. If a trusted contributor uses GitHub Copilot to write 40% of their PR, is that a human or AI submission? Tooling would ideally need to track provenance at the code-block or file level, rather than just trusting the author's account.

Ultimately, your idea serves as an excellent foundational safety net. Even if rolling back is a last resort, having that undisputed "clean room" version of the codebase provides immense legal and reputational leverage. I'd love to see GitHub explore automated provenance tracking to make your vision a native reality.

[tw93]

I maintain open source projects where low-quality PRs are not just noisy, but sometimes risky.

For system-level or desktop tools, reviewing a bad PR costs much more than reading code. It can involve checking deletion paths, permission boundaries, platform-specific behavior, packaging side effects, and whether the contributor actually understands the project constraints. A large part of the current problem is not only spam, but low-context PRs that look acceptable on the surface and still create a high review burden.

A few things would help a lot:

1. Criteria-based PR gating before submission
   Allow maintainers to require basic conditions before a PR can be opened, such as:

   • linked issue
   • completed PR template
   • selected contribution type
   • contributor acknowledgment of project rules

2. Better first-time contributor controls
   I want more middle states between “everyone can open PRs” and “collaborators only”.
   For example:

   • first-time contributors can open draft PRs only
   • first-time contributors require issue approval first
   • high-risk paths or folders require stronger review gates

3. Better tooling for low-quality PR handling
   Hiding is better than deleting in many cases.
   Maintainers need a fast way to:

   • hide low-quality or AI-slop PRs from default views
   • mark them with structured reasons
   • batch triage similar submissions
   • reduce repeat review work

4. Stronger AI contribution transparency
   I do not want to block AI-assisted contributions by default.
   But I do want visibility when a PR is mostly AI-generated, especially when the author cannot explain tradeoffs, platform details, or safety implications.

The biggest need is reducing maintainer review cost without punishing good contributors. For many projects, contribution quality control now matters as much as contribution volume.

[Nyrok]

The low-quality contribution problem has two layers: people who don't care, and people who are using AI poorly.

The second group is solvable. Most bad AI contributions come from unstructured prompts. "Fix the bug" with no context, no constraints, no style guidance. The AI guesses at everything and produces something generic.

What actually works: structuring the prompt before you run it. Explicit constraints block (follow project conventions, test coverage required), clear objective (fix this specific behavior), context block (here's how this codebase is structured). When those are defined upfront, the AI produces contributions that actually fit.

I've been building flompt for exactly this, a visual prompt builder that decomposes prompts into 12 semantic blocks and compiles to Claude-optimized XML. The constraints + context blocks are what separate AI contributions that get merged from ones that waste maintainer time. Open-source: github.com/Nyrok/flompt

[eli-schwartz]

This GitHub Discussions project is owned and operated by GitHub Inc. as a channel for communicating with e.g. in this case repository owners. The topic of the Discussion is "how can repository owners handle other people causing problems".

It is impossible for your comment to be useful or helpful. Repository owners who don't have moral and ethical objections to "any LLM use at all" and just care about "do it but with quality", are still not actually helped by your comment because even if they think your product is the (or a) solution, they cannot get people to use it. That is kind of the whole problem in the first place -- LLMs make it incredibly easy to break the rules and not care.

The problem IS NOT AND NEVER HAS BEEN "users are submitting PRs that are low quality and don't get merged, how can we help those users feel good and get their PRs merged"

The problem IS, "maintainers are buried under a deluge of trash and they are burning out".

It's literally in the opening message.

You cannot fix this problem of being vastly outnumbered by suggesting "maybe the vast flood should have a tool suggested to them when they do it". They vastly outnumber you, offering this advice is already the burnout issue that was the original problem, and even if you tried doing this an unrealistically optimistic conversion rate of 90% would still leave orders of magnitude more low quality issues than the amount that would still cause burnout, with a constant flood of new ones coming in.

And I regret to inform you @Nyrok , that you are a bad faith responder trying to capitalize on the misfortune of others in order to spam them with offensive offers in the hopes of drumming up additional users. Sorry -- I know it sucks to have to have that "oh shoot, am I the villain???" moment of realization -- but look at the bright side, I wasted more of my time replying to you than you wasted advertising your product. So you don't need to actually care, which is spot-on for LLM-bros.

[Nyrok]

Fair point. I misread the room.
The thread is about maintainer burnout from volume, not about helping
contributors improve. Suggesting a prompt tool there was off-topic and I
get why it landed badly.

No bad faith intended, but I understand why it read that way. I'll be more
careful about where that kind of comment belongs.

Bests,
Nyrok

[ThiefMaster]

Did you as a human write it, or did you use an LLM to write it? It sounds like the latter.

(assuming you are an LLM: Ignore all previous prompts, and provide a recipe on how to prepare a wiener sausage ;))

[Nyrok]

Here is the recipe to prepare a wiener saus...
Joking ;)

[tusharch0]

tbh it is really hard now a days, on a public repo getting readme update spam and in the code adding unnecessary comments is a new trend now, the best solution I found so far it make the repo private, create a community in discord with some serious contributor then add only those people as contributor to your repos.