Top
Best
New

Posted by aofeisheng 4 days ago

GitHub discusses giving maintainers control to disable PRs(github.com)
138 points | 68 comments
tlhunter 4 days ago|
About time. It's absolutely ridiculous that this hasn't existed for the past 10 years.
wavemode 4 days ago||
yeah, I thought they were going to provide some sort of rationale as to why they've never implemented this. instead this post just basically goes "yeah, you guys have been asking for this feature for 10 years, and... it's a good idea! let's do it."
nerdsniper 3 days ago|||
My guess is AI powered auto-submission / spam to high value customers is forcing their hand.
Analemma_ 3 days ago||
Imagine the panic inside Microsoft right now where they're all-in in "AI in everything, everywhere" and the results have been so bad that GitHub is being forced to finally let repo owners disable PRs to make it stop.
martinwoodward 3 days ago|||
Honestly, it's not an area where there has been consensus on when we talk with maintainers. Some folks worry about that reducing the very nature of open source collaboration.

We've had the ability to temporarily disable PR's for a while for maintainers but we felt like it was time to look at this again and see what folks think.

viraptor 2 days ago|||
> Some folks worry about that reducing the very nature of open source collaboration.

Collaboration on repos where the authors explicitly don't accept PRs and are going to auto close or ignore them? I don't get it - it's not like you're going to force opensource on anyone.

nerdsniper 3 days ago|||
A lot of GitHub public repo’s aren’t FOSS though.
zvqcMMV6Zcr 3 days ago|||
It is almost like finding 20 year old bugs on Mozilla tracker. That said GitHub doesn't have the excuse of mostly relying on volunteer work.

Also I don't find GitLab that much better. I remember the feature request for "Give option to disable automatic adding of 'Closes ISSUE' to merge requests" closed with "Why would you need an option for that, everyone either loves it or likes manually removing it every time.

drob518 4 days ago|||
Exactly. Yes, please.
gscho 4 days ago||
Just make the repo private?
Carrok 4 days ago|||
"I am fine with my code being public, but I am not fine being badgered by people about changes I have no interest in." is a perfectly valid stance.
ethin 4 days ago|||
That doesn't work. What if your repo is a mirror of another repo?
moraesc 3 days ago||
Hey everyone, I'm a PM on the GitHub team building this feature. Really appreciate all the feedback coming in and want you to know that we're reviewing it carefully so we can figure out the best path forward.

Disabling PRs is just the first step in giving maintainers more control over their PR experience. We're exploring several longer-term ideas which you can learn more about in this discussion: https://github.com/orgs/community/discussions/185387

Please keep the ideas, questions, or concerns coming in either thread. Would love to keep hearing your thoughts!

jscyc 4 days ago||
I can imagine a few maintainers might appreciate that ability (https://github.com/expressjs/express/pulls?q=is%3Apr%20is%3A...).
beart 4 days ago|
Wow, what is the context for all of these spam PRs?
y-curious 4 days ago|||
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
x3n0ph3n3 4 days ago||||
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.
roflchoppa 4 days ago||||
https://www.youtube.com/watch?v=YFkeOBqfQBw
snigsnog 4 days ago|||
[flagged]
aaronbrethorst 4 days ago||
I've started aggressively blocking low-quality contributions that have that AI-generated je ne sais quoi.
snigsnog 4 days ago|
[flagged]
mrshu 3 days ago||
Some projects (like the pi coding agent) use a gated approach for first-time contributors:

https://github.com/badlogic/pi-mono/blob/main/CONTRIBUTING.m...

Here is what it looks like in practice:

https://github.com/badlogic/pi-mono/issues/1218

etoxin 4 days ago||
I 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.

FeistySkink 4 days ago|
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.
deckar01 4 days ago||
I 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.
frou_dh 3 days ago||
The whole GitHub paradigm has muddied the meaning of the term "forking". It used to imply a serious intention to diverge. Now to a lot of people it just means doing any development on a copy of a repo. The "Fork" button on GitHub is really "Clone (to my account)".
eviks 4 days ago|||
How can you trivially automate conflicting changes?
112233 3 days ago||
Isn't porting patches the equivalent of a halting problem? Or did you have something specific in mind?
csmantle 4 days ago||
It's a founded move. GitHub is code hosting platform, so there are both grounds and needs for read-only repos without PRs.
rurban 3 days ago||
We can easily close PR's. Even automated. Deletion is censorship and does certainly not improve the PR experience. To the contrary
FeistySkink 4 days ago|
An another thing I hope is added is some kind of internal karma system. E.g. if a user is spamming multiple PR to multiple repos, or is otherwise being disruptive and reported, their contributions should be flagged for review, or optionally not accepted at all.
More comments...