5 ms·

GitHub discusses giving maintainers control to disable PRs

139 points by aofeisheng 8mo ago

tlhunter 8mo ago
About time. It's absolutely ridiculous that this hasn't existed for the past 10 years.
- drob518 8mo ago
  Exactly. Yes, please.
- gscho 8mo ago
  Just make the repo private?
  - ethin 8mo ago
    That doesn't work. What if your repo is a mirror of another repo?
  - Carrok 8mo 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.
- wavemode 8mo 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."
  - martinwoodward 8mo 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.
    - nerdsniper 8mo ago
      A lot of GitHub public repo’s aren’t FOSS though.
    - viraptor 8mo 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 8mo ago
    My guess is AI powered auto-submission / spam to high value customers is forcing their hand.
    - Analemma_ 8mo 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.
- zvqcMMV6Zcr 8mo 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.
zekenie 8mo ago
They 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.
- Supermancho 8mo ago
  > 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".
  - zekenie 8mo ago
    The increased review burden is also happening inside companies. It’s genuinely hard to keep up with the volume. I was a little surprised to see my comment downvoted. I’m not saying we shouldn’t be able to delete slop PRs. Of course we should! I’m saying that the pr should change at least _somewhat_ in response to how much programming is changing. Also worth stating that I have been ranting about contract first reviews for 10 years and it’s not just in response to llm written code.
jscyc 8mo ago
I can imagine a few maintainers might appreciate that ability (https://github.com/expressjs/express/pulls?q=is%3Apr%20is%3Aclosed%20is%3Alocked%20 https://github.com/expressjs/express/pulls?q=is%3Apr%20is%3A...).
- beart 8mo ago
  Wow, what is the context for all of these spam PRs?
  - roflchoppa 8mo ago
    https://www.youtube.com/watch?v=YFkeOBqfQBw https://www.youtube.com/watch?v=YFkeOBqfQBw
  - x3n0ph3n3 8mo 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.
  - y-curious 8mo 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
    - undermineduser 8mo ago
      I am from India and i would like to apologize for this matter. :(
  - snigsnog 8mo ago
    [flagged]
csmantle 8mo ago
It's a founded move. GitHub is code hosting platform, so there are both grounds and needs for read-only repos without PRs.
aaronbrethorst 8mo ago
I've started aggressively blocking low-quality contributions that have that AI-generated je ne sais quoi.
- snigsnog 8mo ago
  [flagged]
etoxin 8mo 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 8mo 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 8mo 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.
- eviks 8mo ago
  How can you trivially automate conflicting changes?
- 112233 8mo ago
  Isn't porting patches the equivalent of a halting problem? Or did you have something specific in mind?
- frou_dh 8mo 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)".
notepad0x90 8mo ago
I hope someone can explain the sentiment on HN to me. I don't get it, why is this popular? I want to know how many PRs a project is getting, but more than that how receptive the maintainers are. Issues don't tell the whole picture, because work gets backlogged, and you can't expect people doing this for free to have an SLA or something. but PRs.. the work is ideally at least mostly done. There is the one project for example, very popular in the industry it's used in. There is a specific use-case that I run into repeatedly, that it fails at. The project has lots of open issues (understandably), and there are multiple PRs to address that, but the maintainers give no good reason for not accepting it. I've been using some random guy's branch (who isn't even keeping up with the latest releases and backporting) for many years now, waiting for the maintainers to either reject it or accept the PR. Lots of people upvote, comment, and beg. I want to see how maintainers handle that. This is really bad. I'd prefer if they stopped reporting of issues instead of PRs. Issues is providing support, PRs let other people who fixed something or added a feature attempt to contribute. You can't just "fork it", that means you have to be the maintainer now. And how will people even find your "fork" which may have fixed things? I'd like to be able to at least find open and unmerged forks with a fix in place I could apply, even if the maintainer never got around to it. Turning PRs off is the software equivalent of hardware makers turning off support for aftermarket parts. Honestly, if you don't like PRs, ignore them like many already do. Does it look bad when you do that? Yes. As it should! Don't hide away from your preferences, own it. Let other people get access to fixes you either have no time to get to, or unwilling to implement. Just the discussions alone on security related issues (or PRs as in this case) is telling sometimes.
- FeistySkink 8mo ago
  So you don't want to maintain a fork, but want a maintainer to do it for free for you and wondering why that PR is not accepted? If you feel so strongly about the project popular in your 'industry', consider providing some incentive for the maintainer to care. And no, a coffee is not an incentive. Edit: this probably came off quite abrasive, but I'm getting entitled comments from users with no contributions, demanding fixes for their most ridiculously niche issues almost weekly. Like stuff doesn't build with their toolchain from 2014. Seriously? Yet, they can't be arsed to even check the fixes or follow up with basic details.
FeistySkink 8mo 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.
everfrustrated 8mo ago
I'd like to see the ability for projects to require a payment before allowing an Issue to be opened. Open source doesn't mean labor should be free. Would be a great way to support maintainers etc spending time investigating bug reports etc.
- Woshiwuja 8mo ago
  [dead]
- rurban 8mo ago
  Absolutely not. That's the easiest way to kill a project.
mrshu 8mo 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.md#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 https://github.com/badlogic/pi-mono/issues/1218
moraesc 8mo 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 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!
- undermineduser 8mo ago
  Hi, There are still some projects and community which requires external contributor to contribute to their open source projects to grow open source community and people who are beginner in open source. these communities and projects are still vulnerable to the AI and spam PRs. for those kind of people how can this help. My suggestion on this take you should add an option to maintainer to flag the user if they are doing spam and ai slop so if it exceed to a x number it will ban the user. I know this is against the open source philosophy but still it will prevent the open source community from being polluted.
adelet 8mo ago
[dead]
rurban 8mo ago
We can easily close PR's. Even automated. Deletion is censorship and does certainly not improve the PR experience. To the contrary

139 points by aofeisheng 8mo ago

tlhunter 8mo ago

About time. It's absolutely ridiculous that this hasn't existed for the past 10 years.

drob518 8mo ago
Exactly. Yes, please.
gscho 8mo ago
Just make the repo private?
- ethin 8mo ago
  That doesn't work. What if your repo is a mirror of another repo?
- Carrok 8mo 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.
wavemode 8mo 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."
- martinwoodward 8mo 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.
  - nerdsniper 8mo ago
    A lot of GitHub public repo’s aren’t FOSS though.
  - viraptor 8mo 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 8mo ago
  My guess is AI powered auto-submission / spam to high value customers is forcing their hand.
  - Analemma_ 8mo 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.
zvqcMMV6Zcr 8mo 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.

zekenie 8mo ago

They 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.

Supermancho 8mo ago
> 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".
- zekenie 8mo ago
  The increased review burden is also happening inside companies. It’s genuinely hard to keep up with the volume. I was a little surprised to see my comment downvoted. I’m not saying we shouldn’t be able to delete slop PRs. Of course we should! I’m saying that the pr should change at least _somewhat_ in response to how much programming is changing. Also worth stating that I have been ranting about contract first reviews for 10 years and it’s not just in response to llm written code.

jscyc 8mo ago

I can imagine a few maintainers might appreciate that ability (https://github.com/expressjs/express/pulls?q=is%3Apr%20is%3Aclosed%20is%3Alocked%20 https://github.com/expressjs/express/pulls?q=is%3Apr%20is%3A...).

beart 8mo ago
Wow, what is the context for all of these spam PRs?
- roflchoppa 8mo ago
  https://www.youtube.com/watch?v=YFkeOBqfQBw https://www.youtube.com/watch?v=YFkeOBqfQBw
- x3n0ph3n3 8mo 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.
- y-curious 8mo 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
  - undermineduser 8mo ago
    I am from India and i would like to apologize for this matter. :(
- snigsnog 8mo ago
  [flagged]

csmantle 8mo ago

It's a founded move. GitHub is code hosting platform, so there are both grounds and needs for read-only repos without PRs.

aaronbrethorst 8mo ago

I've started aggressively blocking low-quality contributions that have that AI-generated je ne sais quoi.

snigsnog 8mo ago
[flagged]

etoxin 8mo 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 8mo 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 8mo 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.

eviks 8mo ago
How can you trivially automate conflicting changes?
112233 8mo ago
Isn't porting patches the equivalent of a halting problem? Or did you have something specific in mind?
frou_dh 8mo 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)".

notepad0x90 8mo ago

I hope someone can explain the sentiment on HN to me. I don't get it, why is this popular? I want to know how many PRs a project is getting, but more than that how receptive the maintainers are. Issues don't tell the whole picture, because work gets backlogged, and you can't expect people doing this for free to have an SLA or something. but PRs.. the work is ideally at least mostly done. There is the one project for example, very popular in the industry it's used in. There is a specific use-case that I run into repeatedly, that it fails at. The project has lots of open issues (understandably), and there are multiple PRs to address that, but the maintainers give no good reason for not accepting it. I've been using some random guy's branch (who isn't even keeping up with the latest releases and backporting) for many years now, waiting for the maintainers to either reject it or accept the PR. Lots of people upvote, comment, and beg. I want to see how maintainers handle that. This is really bad. I'd prefer if they stopped reporting of issues instead of PRs. Issues is providing support, PRs let other people who fixed something or added a feature attempt to contribute. You can't just "fork it", that means you have to be the maintainer now. And how will people even find your "fork" which may have fixed things? I'd like to be able to at least find open and unmerged forks with a fix in place I could apply, even if the maintainer never got around to it. Turning PRs off is the software equivalent of hardware makers turning off support for aftermarket parts. Honestly, if you don't like PRs, ignore them like many already do. Does it look bad when you do that? Yes. As it should! Don't hide away from your preferences, own it. Let other people get access to fixes you either have no time to get to, or unwilling to implement. Just the discussions alone on security related issues (or PRs as in this case) is telling sometimes.

FeistySkink 8mo ago
So you don't want to maintain a fork, but want a maintainer to do it for free for you and wondering why that PR is not accepted? If you feel so strongly about the project popular in your 'industry', consider providing some incentive for the maintainer to care. And no, a coffee is not an incentive. Edit: this probably came off quite abrasive, but I'm getting entitled comments from users with no contributions, demanding fixes for their most ridiculously niche issues almost weekly. Like stuff doesn't build with their toolchain from 2014. Seriously? Yet, they can't be arsed to even check the fixes or follow up with basic details.

FeistySkink 8mo 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.

everfrustrated 8mo ago

I'd like to see the ability for projects to require a payment before allowing an Issue to be opened. Open source doesn't mean labor should be free. Would be a great way to support maintainers etc spending time investigating bug reports etc.

Woshiwuja 8mo ago
[dead]
rurban 8mo ago
Absolutely not. That's the easiest way to kill a project.

mrshu 8mo 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.md#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 https://github.com/badlogic/pi-mono/issues/1218

moraesc 8mo 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 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!

undermineduser 8mo ago
Hi, There are still some projects and community which requires external contributor to contribute to their open source projects to grow open source community and people who are beginner in open source. these communities and projects are still vulnerable to the AI and spam PRs. for those kind of people how can this help. My suggestion on this take you should add an option to maintainer to flag the user if they are doing spam and ai slop so if it exceed to a x number it will ban the user. I know this is against the open source philosophy but still it will prevent the open source community from being polluted.

adelet 8mo ago

[dead]

rurban 8mo ago

We can easily close PR's. Even automated. Deletion is censorship and does certainly not improve the PR experience. To the contrary