Live data from Hacker News

Pull request limits are cutting down the noise

github.blog

41–50 of 56 posts

Re: Pull request limits are cutting down the noise

#41
post #31

Earlier quoted context omitted.

I actually do that quite often these days. Keeping synced with upstream is trivial these days with a modern agent. Even just pi with DeepSeek V4 Flash can do it. It's a huge free-rider issue, but there's no way for me to contribute even human changes upstream because I'll be lost in the AI contributions so I don't bother. So almost everything is forked and I then just have the agent keep my changes in sync with upstr…

Yep, same here. I hate it a lot, but it's the new reality. It's easier/better for me to just fork, change whatever the hell I want, and push it to my fork. If I become away that upstream wants it I'm happy to put in the work to get a clean merge, but I'm not wasting anymore time pushing things upstream without some indicator that my time is valued by them. Been burned too many time now. It wasn't this way pre-AI, but…

> If I become away that upstream wants it I'm happy to put in the work to get a clean merge, but I'm not wasting anymore time pushing things upstream without some indicator that my time is valued by them. Been burned too many time now.

Do you realize that all the major package system on BSD and Linux works that way. You take upstream, patch it to get it to compile on the system, and then build a package. That is what open source is about. It's not about building a community and what's not.

Re: Pull request limits are cutting down the noise

#42

Earlier quoted context omitted.

Some people have tokens but no money. Tokens, like Amazon gift cards and Tide detergent [1], are a form of currency in a way. If people have a currency equivalent they want to spend for your benefit, or the collective benefit, it makes sense (depending on level of effort) to enable them to do so. [1] How Tide Detergent Became a Drug Currency - https://news.ycombinator.com/item?id=5023204 - January 2013 (124 comments)…

> Some people have tokens but no money. This sounds like a piece of worldbuilding from a Daniel Suarez novel. Who has tokens but no money?

Some AI folks want to bifurcate the meaning of "token" towards a spendable store of value, rather than characters processed by a tokenizer.

"Donate tokens". "Gift tokens". Semantic drift?

Re: Pull request limits are cutting down the noise

#44

The primary spam problem isn't that a single account opens many pull requests on a single repo, but that spammer accounts open many pull requests spread across many repositories. So limiting accounts to a couple of open PRs on my repository won't help much. I'd rather enforce a limit based on the number of PRs that account opened across all public repositories it doesn't have write access to within the last week. And…

Good point. I've (even with agents) never made more than like 5 PRs in one day internal to a company and if I have they typically included accompanying proto or submodule changes. Heck give a factor of safety of 2x and cap at 10 daily PRs per account for repos that youre "untrusted"

Re: Pull request limits are cutting down the noise

#45

Earlier quoted context omitted.

> And PRs that were closed without getting merged should be held against the account somehow That strikes me as a bad solution. I've sent plenty of PRs over the last two decades that were things I wasn't sure if upstream wanted or not, but I did the work and wanted to offer it to them. If you get penalized for not having a PR merged, it's going to incentivize selfishness

That's why I suggested an explicit "close as unwelcome" option (label to be bikeshed). And the impact of the rejection should decay over time. In any case, my proposal is a rough sketch of how I'd approach the problem, not a production ready algorithm. But I'd expect even that basic approach to work a lot better than github's approach.

Really it should be a "report as spam" option

Re: Pull request limits are cutting down the noise

#46

The primary spam problem isn't that a single account opens many pull requests on a single repo, but that spammer accounts open many pull requests spread across many repositories. So limiting accounts to a couple of open PRs on my repository won't help much. I'd rather enforce a limit based on the number of PRs that account opened across all public repositories it doesn't have write access to within the last week. And…

Your proposal wouldn't help me at all. I wouldn't say that the problem I'm having is even "spam" per se. (For context I receive hundreds of PRs each week across my OSS projects like mise)

In my case I sometimes get a flurry of PRs from over-exuberant contributors, not necessarily low quality even! Using this I can at least put some back-pressure on that and help keep things more fair across my contributors.

Re: Pull request limits are cutting down the noise

#47
post #46

The primary spam problem isn't that a single account opens many pull requests on a single repo, but that spammer accounts open many pull requests spread across many repositories. So limiting accounts to a couple of open PRs on my repository won't help much. I'd rather enforce a limit based on the number of PRs that account opened across all public repositories it doesn't have write access to within the last week. And…

Your proposal wouldn't help me at all. I wouldn't say that the problem I'm having is even "spam" per se. (For context I receive hundreds of PRs each week across my OSS projects like mise) In my case I sometimes get a flurry of PRs from over-exuberant contributors, not necessarily low quality even! Using this I can at least put some back-pressure on that and help keep things more fair across my contributors.

why not both?

Re: Pull request limits are cutting down the noise

#48

I think this is a really solid move. This gives OSS contributors a lot of flexibility. You could set the limit to 0, and manually add contributors. You could set it to 1-3 to allow people to get their foot in the door. But the de facto limit today is infinite, which is spammed. Imagine if GMail did this! If I don't whitelist or reply within `n` emails, youre done. I would KILL for that.

> Imagine if GMail did this!

It would be very annoying? Spammers can still spam one message, but now your friends can't email you twice. Awesome.

This is a barely-better-than-nothing blunt tool.

Re: Pull request limits are cutting down the noise

#50

The primary spam problem isn't that a single account opens many pull requests on a single repo, but that spammer accounts open many pull requests spread across many repositories. So limiting accounts to a couple of open PRs on my repository won't help much. I'd rather enforce a limit based on the number of PRs that account opened across all public repositories it doesn't have write access to within the last week. And…

Github needs a "Human Trust" score where "AI Slop" label applied to a PR reduces the score and denies all PR's for the next X hours, delay increasing exponentially for every PR labelled with "AI Slop". Repeated "AI Slop" labels given by a maintainer reduces "Human Trust" Score like dropping off a cliff.

Every successful merge for a PR spread across N days slowly increases "Human Trust" score. (So a slow of fake merged PR's cannot fake increase Human Trust score). Just like the real world, Human Trust should be hard to gain and easy to lose.

If your Human Trust Score becomes negative due to too much "AI Slop", then you are banned from all PR submissions for a quarter. Your profile picture is also replaced with the Robot Identicon to indicate to the world that your human brain has been replaced by AI and urgent health-check is needed.

Post reply on HN