FRESH

Hacker News

Home

GitHub discusses giving maintainers control to disable PRs

136 points by aofeisheng

by tlhunter

4 subcomments

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

by moraesc

0 subcomment

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!

by jscyc

1 subcomments

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

by mrshu

0 subcomment

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

by aaronbrethorst

1 subcomments

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

by etoxin

1 subcomments

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.

by deckar01

3 subcomments

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.

by csmantle

0 subcomment

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

by rurban

0 subcomment

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

by FeistySkink

0 subcomment

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.

by adelet

0 subcomment

[dead]

by everfrustrated

2 subcomments

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.

by zekenie

1 subcomments

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.

by notepad0x90

3 subcomments

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.