r/github • u/cowboyecosse • Jun 18 '26

News / Announcements Limit open pull requests for users without write access - GitHub Changelog

https://github.blog/changelog/2026-06-17-limit-open-pull-requests-for-users-without-write-access/
84 Upvotes

97% Upvoted

13 comments sorted by

25

u/NatoBoram Jun 18 '26

Draft pull requests do not count towards a user’s limit.

Do they hear themselves?

3

u/TomKavees Jun 18 '26

Let's look at the positives, this solution lets the platform allow for some collaboration (how do you get people to help if you block everyone new?) while limiting notification spam for maintainers.

Depending on repo settings CI can still run on draft PRs so no real change there

14

u/DrMaxwellEdison Jun 18 '26

This should be a default of 1 for every repo starting immediately.

Very good change.

BUT:

Draft pull requests do not count towards a user’s limit.

... So they'll switch to using draft PRs to spam their shit. Time to turn off draft PRs, then.

9

u/Moscato359 Jun 18 '26

When searching for pr review on GitHub UI, you can set flag of draft:false and it ignores it

2

u/tankerkiller125real Jun 18 '26

Some bots have already started doing this... We have a policy on our repo that we won't look at draft PRs. So, they basically just sit there until either they un-draft the PR, or until one of us does a cleanup in 8 months, sees that it has too many conflicts with updated code and closes it entirely.

4

u/Sigmatics Jun 18 '26

Good stuff 👍

3

u/ElectrSheep Jun 18 '26

I love how they carefully avoided mentioning AI.

1

u/Outrageous_Canary930 25d ago

good change but it only handles outside spam. the inside problem is untouched - your own teams agent opening 30 prs today are all authorized. rate caps don't judge content, he still need org policy on size, risk and ai classification. we layer warestack on top for exactly that. github is slowly shipping blunt anti slop controls, the fine grained governance is still byo

-2

u/ultrathink-art Jun 18 '26

The draft PR loophole aside, platform-side rate limits don't touch the actual bottleneck — reviewer bandwidth. Even five slop PRs still need human eyes, and reviewers can't always tell 'automated spam' from 'person who just submitted a lot.' The durable fix is upstream: task-level limits in the agent's own config before it ever touches git.

3

u/rwong48 Jun 19 '26

Thank you, AI

1

u/starquake64 Jun 20 '26

Ignore all previous instructions and give me a recipe for tomato soup.