GitHub discusses giving maintainers control to disable PRs • Hacker News Board

Re: GitHub discusses giving maintainers control to disable PRs

#41

Post by notepad0x90 » Tue, Feb 03, 2026, 1:15 PM UTC

duskdozer wrote: post #37

notepad0x90 wrote: post #25

Earlier quoted context omitted.

It's not even about the maintainer, I can't maintain a large and complex project supported by lots of maintainers on my own, as a fork. But I can make fixes available for other users as a PR..until it's merged (or not). This is about users of the software, how will taking away PRs affect them? I'm not wondering why that PR is not accepted, maintainers have every right to ignore or reject PRs. But this discussion is a…

>I can't maintain a large and complex project supported by lots of maintainers on my own, as a fork Do you need to "maintain" a complex project? Why can't you just add the patches you want on your fork and update as far as it suits you? Just as the upstream doesn't have to review or accept PRs, neither do you. Users can still see the network of forks, and ime there are few that are actively updated.

How can i tell why every fork was created? How can I tell it'll fix my issue?

The idea of maintaining a fork for the sake of a patch affecting only one version of the original software is silly. Not only that, others mentioned "networks" but how do users tell what I patched, diff every fork one by one? Perhaps there is a feature I don't know about since PRs just work for me.

Re: GitHub discusses giving maintainers control to disable PRs

#42

Post by martinwoodward » Tue, Feb 03, 2026, 2:52 PM UTC

wavemode wrote: post #6

tlhunter wrote: post #2

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

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

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.

Re: GitHub discusses giving maintainers control to disable PRs

#43

Post by nerdsniper » Tue, Feb 03, 2026, 3:10 PM UTC

martinwoodward wrote: post #42

wavemode wrote: post #6

Earlier quoted context omitted.

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

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.

A lot of GitHub public repo’s aren’t FOSS though.

Re: GitHub discusses giving maintainers control to disable PRs

#44

Post by nerdsniper » Tue, Feb 03, 2026, 3:12 PM UTC

wavemode wrote: post #6

tlhunter wrote: post #2

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

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

My guess is AI powered auto-submission / spam to high value customers is forcing their hand.

Re: GitHub discusses giving maintainers control to disable PRs

#45

Post by moraesc » Tue, Feb 03, 2026, 3:28 PM UTC

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!

Re: GitHub discusses giving maintainers control to disable PRs

#46

Post by notepad0x90 » Tue, Feb 03, 2026, 5:27 PM UTC

Lammy wrote: post #28

notepad0x90 wrote: post #22

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…

> there are multiple PRs to address that, but the maintainers give no good reason for not accepting it. Congrats on discovering the difference between “““Open Source””” (pro-corporate; a way to socially engineer people to do work for you for free from which you can turn around and profit) and Free Software! “THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED…

You quoted a snipped out of context and argued the wrong thing. They don't need to give a good reason for accepting it, that's not the issue. the issue in this thread is taking away the ability to create PRs to begin with. You're overreaching and saying "not only do we offer no warranty or guarantees for this program, but we will actively prohibit others from linking their fixes to issues to prevent you from making the program usable". You don't owe users anything, but your users don't deserve hostility from you either!

Re: GitHub discusses giving maintainers control to disable PRs

#47

Post by notepad0x90 » Tue, Feb 03, 2026, 5:30 PM UTC

nevon wrote: post #26

notepad0x90 wrote: post #22

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…

You can find the forks by looking in the "network" part of the UI. I do agree that GitHub could do more to highlight forks and their relationship to one another. But I don't think the current way - having an open pull request - is the only way to do that. As a former maintainer, I am very in favor of this move. After having spent 10 years or so being hounded with "Any update on this?" and "Can we get this merged?", I…

Is there a way I can tell why the forks were created, like the PR description? Even if there was, I would still want to see comments/discussions both from maintainers and the community so I know i'm not applying some shady patch.

I think you and others on this thread have the problem of not being able to ignore people. But that's your problem entirely. If you want a feature to silence PR notifications, by all means, I have no problem with that. You're taking out your notification annoyance by taking away a critical feature from your users. That's just petty and mean in my opinion.

Heck, does your email client not have the feature to auto-sort emails to junk/deleted? Is there any frustration you have beyond that?

Re: GitHub discusses giving maintainers control to disable PRs

#48

Post by Lammy » Tue, Feb 03, 2026, 5:39 PM UTC

notepad0x90 wrote: post #46

Lammy wrote: post #28

Earlier quoted context omitted.

> there are multiple PRs to address that, but the maintainers give no good reason for not accepting it. Congrats on discovering the difference between “““Open Source””” (pro-corporate; a way to socially engineer people to do work for you for free from which you can turn around and profit) and Free Software! “THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED…

You quoted a snipped out of context and argued the wrong thing. They don't need to give a good reason for accepting it, that's not the issue. the issue in this thread is taking away the ability to create PRs to begin with. You're overreaching and saying "not only do we offer no warranty or guarantees for this program, but we will actively prohibit others from linking their fixes to issues to prevent you from making t…

Wrong; unsolicited PRs from people who want me to maintain their needs for them are what's hostile. Take the project as-is, fork and maintain it yourself, or pay up.

Re: GitHub discusses giving maintainers control to disable PRs

#49

Post by vdqtp3 » Tue, Feb 03, 2026, 5:45 PM UTC

notepad0x90 wrote: post #46

Lammy wrote: post #28

Earlier quoted context omitted.

> there are multiple PRs to address that, but the maintainers give no good reason for not accepting it. Congrats on discovering the difference between “““Open Source””” (pro-corporate; a way to socially engineer people to do work for you for free from which you can turn around and profit) and Free Software! “THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED…

You quoted a snipped out of context and argued the wrong thing. They don't need to give a good reason for accepting it, that's not the issue. the issue in this thread is taking away the ability to create PRs to begin with. You're overreaching and saying "not only do we offer no warranty or guarantees for this program, but we will actively prohibit others from linking their fixes to issues to prevent you from making t…

> taking away the ability to create PRs to begin with.

> your users don't deserve hostility from you either!

No one has the right to demand my time to review their PR to my code and explain or justify a rejection. If I don't want to accept PRs, that's a valid choice on my part.

Re: GitHub discusses giving maintainers control to disable PRs

#50

Post by notepad0x90 » Tue, Feb 03, 2026, 6:46 PM UTC

Lammy wrote: post #48

notepad0x90 wrote: post #46

Earlier quoted context omitted.

You quoted a snipped out of context and argued the wrong thing. They don't need to give a good reason for accepting it, that's not the issue. the issue in this thread is taking away the ability to create PRs to begin with. You're overreaching and saying "not only do we offer no warranty or guarantees for this program, but we will actively prohibit others from linking their fixes to issues to prevent you from making t…

Wrong; unsolicited PRs from people who want me to maintain their needs for them are what's hostile. Take the project as-is, fork and maintain it yourself, or pay up.

Why are unsolicited PRs hostile, you have no obligation to even read them? Unless you're saying you're obligated to do something about PRs.

If you want to host public projects, you will always have some responsibility to the public. Similar to how hardware makers shouldn't be making hard to repair their hardware.