I can imagine a few maintainers might appreciate that ability ( https://github.com/expressjs/express/pulls?q=is%3Apr%20is%3A... ).
Wow, what is the context for all of these spam PRs?
GitHub discusses giving maintainers control to disable PRs
11–20 of 75 posts
Re: GitHub discusses giving maintainers control to disable PRs
#12I can imagine a few maintainers might appreciate that ability ( https://github.com/expressjs/express/pulls?q=is%3Apr%20is%3A... ).
Wow, what is the context for all of these spam PRs?
Advise from low-quality bootcamp-like training programs that encourage open-source contribution, providing low-quality examples of such contribution, in order to improve one's resume and career chances.
Re: GitHub discusses giving maintainers control to disable PRs
#13It's a founded move. GitHub is code hosting platform, so there are both grounds and needs for read-only repos without PRs.
Re: GitHub discusses giving maintainers control to disable PRs
#14I've started aggressively blocking low-quality contributions that have that AI-generated je ne sais quoi.
Re: GitHub discusses giving maintainers control to disable PRs
#15I think we should still allow open contribution to OSS.
Maybe, a "Contributor Requests".
It would be a gate for new contributors. For maintainers, they would see what they have contributed to and see their new PR. It would show "open contributor requests"
Once approved, The PR will then appear under PRs.
And obviously this is opt in.
Re: GitHub discusses giving maintainers control to disable PRs
#16I can imagine a few maintainers might appreciate that ability ( https://github.com/expressjs/express/pulls?q=is%3Apr%20is%3A... ).
Wow, what is the context for all of these spam PRs?
Tldw: a popular YouTube video on “how to open a PR on GitHub” by an Indian channel (targeting Indian audiences) showed how to add their name to a PR step by step. The rest is just the scale of the Indian population in action. I hope the maintainers of expressjs can rest easy
Re: GitHub discusses giving maintainers control to disable PRs
#17They need to talk about how the pr itself should change. The text diff just is not the right thing to center. We should be using ai to chunk changes into reviewable bytes and to align on semantics and contracts.
> They need to talk about how the pr itself should change.
When PRs are spammed, it's impractical to discuss each submitted change. The existence of the PRs interferes with the ability of maintainers to continue making directed changes.
> We should be using ai to chunk changes into reviewable bytes and to align on semantics and contracts.
That statement is a convoluted version of the narcissist's entitlement. ie "other people should realize my vision".
Re: GitHub discusses giving maintainers control to disable PRs
#18I think we should still allow open contribution to OSS. Maybe, a "Contributor Requests". It would be a gate for new contributors. For maintainers, they would see what they have contributed to and see their new PR. It would show "open contributor requests" Once approved, The PR will then appear under PRs. And obviously this is opt in.
I like the idea. Right now it's only possible to require approval for actions for new contributors. But once they get a PR in, they're free to spam new PRs that can clog resource-expensive pipelines. Would be nice to have something like 5+ PRs merged and be a contributor for 1 month before a PR is auto created and actions are allowed to run.
Re: GitHub discusses giving maintainers control to disable PRs
#19I have always been an advocate of forking, despite the overhead of maintaining patches, but porting patches should be trivial to automate now. There needs to be an easy way to publish, discover, and require community patches even if they don’t have the maintainer’s blessing.