GitHub discusses giving maintainers control to disable PRs

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.

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.

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 don't think I would ever do it again as long as there aren't controls in place to be able to set the expectation that the code is free to do with as you will, and please go ahead and fork if you want it to do something different.

> 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 IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.”

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.