Hacker News Reader

Comment by guidoiaquinti | Hacker News Reader

GitHub just recently added configurable PR limits for maintainers to help partially address this problem: https://github.blog/open-source/maintainers/how-pull-request...

View on HN

> At OpenClaw we get a huge volume of pull requests from the community and had to build our own bots for fighting spam.

I find it ironic that the people who originate the idea of AI-code-spam are being negatively impacted by this.

But all they will do is build an AI agent to review the code written by an AI agent, that probably never needed to be written to begin with.

A real leopards ate my face moment

Open source has solved harder problems before.

They're also happy to leave it to "open source" to navigate the fall out.

I would not be at all surprised if Github adds a first party reputation system. It would be a clever way to increase network effects - imagine if you host on Codeberg you're inundated by AI PRs but on Github you can easily filter them out.

I can't see those pull request limits working very well. It's like trying to filter email spam by just rate limiting people. It's going to be annoying for the people you actually want to talk to, and you're still going to get at least 1 spam message from every spammer out there.

If we want to keep it objective, one metric can already be calculated based on the user history of the submitter. The spammers profile will be full of unmerged or abandoned prs. Just based on those statistics beginners might be close to zero rating but spammers would be negative.

Unless I totally missed that people are also making new accounts of each PR.

Prs are too pad cv's or novice users wanting something and vibe coding it themselves. Jellyfin player repos see a lot these kinds of prs so unlikely to be new users

Create lots of fake repos/prs to improve your ratio?

Stars are a really bad metric for quality/popularity but they're something here. I think some sort of impact score when combined with repo age, # contributors, etc would be pretty valuable.

Or creating repos that will merge their PR(s).

> Draft pull requests will not count towards your limit.

Disappointing, it seems that those also need limits too, although the limit could be higher.

I could easily see the limit for PRs be at 1 for untrusted contributors, and drafts at 3-5.

It would be cool if they took the approach Flickr does to groups. You can submit your photo to groups (a kind of curated collage, usually with a certain theme or aesthetic). But the admin can have certain rules, like the photo can only be submitted to a certain number of groups in total, or a limit on how many photos you submit. Some groups are interesting with rules like you can submit only a single picture.

I'd just limit the total. Otherwise people will use it to game the system.

Or using it correctly... depends on what your system is, or more accurately, your policy on reviewing or quickly merging PRs with "Draft" status.

As long as it's taken as an indicator for WIP, it works. It just doesn't work when acting illiterate of this distinction; and I have often have had PRs switched to "ready", reviewed + merged in a couple of hours.

But when the change list grows, and the PR ages, while still being intentionally maintained, the Draft signal is strong and helpful IMO. Switching an old Draft PR to "ready" after reviving it with changes seems like a useful signal to me.

I think you're missing the point. Limiting the number of PRs, but not counting draft PRs, just means the SPAM PRs will all be drafts. This solves (almost) nothing.

> Or using it correctly...

Note that people using AI to make spam pull requests are not using the system correctly.

Reply on news.ycombinator.com