GitHub discusses giving maintainers control to disable PRs
github.com105 points by aofeisheng 9 hours ago
105 points by aofeisheng 9 hours ago
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."
Just make the repo private?
"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.
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?
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
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.
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.
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.
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.
I've started aggressively blocking low-quality contributions that have that AI-generated je ne sais quoi.
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.
Isn't porting patches the equivalent of a halting problem? Or did you have something specific in mind?
It's a founded move. GitHub is code hosting platform, so there are both grounds and needs for read-only repos without PRs.
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.
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.
> 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".
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.
> 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.”
Too late to edit, but here's the inarguable truth straight from the mouth of the Open Source Initiative, that the term was the direct product of Netscape's desire to get people to work for them for free: https://opensource.org/history
“The ‘open source’ label was created at a strategy session held on February 3rd, 1998 in Palo Alto, California, shortly after the announcement of the release of the Netscape source code. […] The conferees believed the pragmatic, business-case grounds that had motivated Netscape to release their code illustrated a valuable way to engage with potential software users and developers, and convince them to create and improve source code by participating in an engaged community. The conferees also believed that it would be useful to have a single label that identified this approach and distinguished it from the philosophically- and politically-focused label ‘free software.’”
Open source is not open contribution. There are many examples of open source, but closed contribution, e.g. SQLite.
What you are listing is a business strategy of a company (free labor and advertising). Desires of a company are very different from an unpaid volunteer.
In projects that leave PRs unanswered, the maintainer is already unpaid labor, but contributor want him to work on the contribution. That might not align with what maintainer wants.
Edit: Personally, I find reviewing least pleasant part of dev work. Thanks to LLMs, that now also significantly more of my paid work. My desire to do code reviews in my free time is massively lower. I would rather do it myself.
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.
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.
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 about taking away the ability to even create PRs that other users of the software an discover. This is a user-hostile behavior fueled solely by laziness and pettiness.
> This is a user-hostile behavior fueled solely by laziness and pettiness.
Damn, that last quip is really poisoning the well here. As a maintainer, not being paid for my projects or contributions, I have every right to decide how and if I want to accept contributions.