alt Hacker NewsThe 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 PRs that were closed without getting merged should be held against the account somehow (perhaps via a "close as unwelcome" option for the maintainer).
Replies
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.
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"
> 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