Live data from Hacker News

GitHub discusses giving maintainers control to disable PRs

github.com

51–60 of 75 posts

Re: GitHub discusses giving maintainers control to disable PRs

#51
post #49

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…

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

I feel like I'm not even speaking english on this thread. I've said MANY times that project owners owe nothing to anyone, period. You don't owe anything. Ignore the PRs, send them to your junk folder. I don't care.

That has nothing to do with this discussion.

People have a right to propose changes to broken things they use. Your right to ignore them and not provide support is a two-way street. Others also have a right to ignore what you want and propose changes for other users to see.

it's right there is name of the feature "Pull Request", it's a request, not a demand.

If you were operating a non-profit business in person, you can't get mad at people suggesting changes either. You can ignore them for sure, you can pull up some disclaimer or whatever. But it's hostile and mean to prevent people from even stating their opinions and proposing a change.

At that point, make your project private.

You don't owe the public many things, but when you create a project and make it public on a shared hosting site, other users also have rights to make commentary, since you've exposed it as public, and proposals and to assist each other. I'd even go further to say that this counts as intentional interference with users' attempt to fix vulnerable and buggy code, and as such an intentional attempt to harm the public. It's one thing to not guarantee anything about your software, it's another thing to prevent people from trying to fix it.

Re: GitHub discusses giving maintainers control to disable PRs

#52
post #48

Earlier quoted context omitted.

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.

> If you want to host public projects, you will always have some responsibility to the public.

I disagree with this completely.

Re: GitHub discusses giving maintainers control to disable PRs

#53
post #49

Earlier quoted context omitted.

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

I feel like I'm not even speaking english on this thread. I've said MANY times that project owners owe nothing to anyone, period. You don't owe anything. Ignore the PRs, send them to your junk folder. I don't care. That has nothing to do with this discussion. People have a right to propose changes to broken things they use. Your right to ignore them and not provide support is a two-way street. Others also have a righ…

> People have a right to propose changes to broken things they use.

Here's the root of your misunderstanding. “Broken” is subjective, relative only to you.

> it's right there is name of the feature "Pull Request", it's a request, not a demand.

That's marketing-speak. It is absolutely a demand. PRs are a growth-hacking feature and are part of how GitHub got to be so dominant. The abuse of social pressure calling someone's project unmaintained was the same mechanism used for the XZ Utils backdoor: https://securelist.com/xz-backdoor-story-part-2-social-engin...

Re: GitHub discusses giving maintainers control to disable PRs

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

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

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.

Re: GitHub discusses giving maintainers control to disable PRs

#55

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.

Absolutely not. That's the easiest way to kill a project.

Re: GitHub discusses giving maintainers control to disable PRs

#57
post #52

Earlier quoted context omitted.

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.

> If you want to host public projects, you will always have some responsibility to the public. I disagree with this completely.

If you plant a public tree for example, you may not be responsible if the tree produces a poisonous fruit or not, but if someone puts a sign next to the tree telling people "boil before eating,otherwise it's poisonous", that's their right. But if you don't want your tree to look bad and prevent them from doing so, now you're responsible for any poisoning from the tree. You can either be responsible or not responsible, but you can't be __irresponsible__. You can't act in a manner that you know will harm others, when not doing so costs you nothing, not even a perception of obligation.

If you have the right to turn off PRs, any company out there also has the right to make thing that are hard to repair. I don't want to say anyone who agrees with you on this thread complaining about Google or some other company shutting down your accounts with no explanation either.

Re: GitHub discusses giving maintainers control to disable PRs

#58
post #53

Earlier quoted context omitted.

I feel like I'm not even speaking english on this thread. I've said MANY times that project owners owe nothing to anyone, period. You don't owe anything. Ignore the PRs, send them to your junk folder. I don't care. That has nothing to do with this discussion. People have a right to propose changes to broken things they use. Your right to ignore them and not provide support is a two-way street. Others also have a righ…

> People have a right to propose changes to broken things they use. Here's the root of your misunderstanding. “Broken” is subjective, relative only to you. > it's right there is name of the feature "Pull Request", it's a request, not a demand. That's marketing-speak. It is absolutely a demand. PRs are a growth-hacking feature and are part of how GitHub got to be so dominant. The abuse of social pressure calling someo…

> Here's the root of your misunderstanding. “Broken” is subjective, relative only to you.

This is not a misunderstanding. I want to know what other people subjectively think is broken, and their proposed fixes. So, if I agree with them, I can opt to use their fixes. A lot of time the developer does not want to maintain the added complexity, or does not agree with architectural or design decisions by the contributor, and that's fine. But I, as a user might agree with the contributor. it costs you, as the maintainer nothing to let people propose changes. nothing at all. as others have repeated many times on this thread, you're not even obliged to respond to PRs, it won't even cost you appearance or reputation. You're just annoyed, that's it, and instead of ignoring the thing that annoys you, the solution is hostility.

> That's marketing-speak. It is absolutely a demand.

If you have a contributor policy clearly defined, it isn't. When you publish a project for the public, people will use it, that's the expectation.

Perhaps if github linked your contributor policy that might help. You can also setup an action that will auto-close all PRs, commenting your contributor policy for everyone to see the reason. There are many ways to handle this, but people on this thread are choosing the lazy option that harms users the most. I think part of it might be that many of you have not dealt with projects that benefit heavily from PRs.

Re: GitHub discusses giving maintainers control to disable PRs

#59
post #52

Earlier quoted context omitted.

> If you want to host public projects, you will always have some responsibility to the public. I disagree with this completely.

If you plant a public tree for example, you may not be responsible if the tree produces a poisonous fruit or not, but if someone puts a sign next to the tree telling people "boil before eating,otherwise it's poisonous", that's their right. But if you don't want your tree to look bad and prevent them from doing so, now you're responsible for any poisoning from the tree. You can either be responsible or not responsible…

> If you have the right to turn off PRs

Joke's on you; I already do shut down every PR automatically on my projects with the repo-lockdown bot: https://github.com/marketplace/actions/repo-lockdown

Making my code public at all is what costs me nothing. I am already writing it. I am already versioning it with Git. Giving you access to it is either a no-op or is some amount of public good. It can never be a negative. This is what Free Software is. Read Stallman: https://www.gnu.org/philosophy/free-sw.html#four-freedoms

Re: GitHub discusses giving maintainers control to disable PRs

#60
post #53

Earlier quoted context omitted.

> People have a right to propose changes to broken things they use. Here's the root of your misunderstanding. “Broken” is subjective, relative only to you. > it's right there is name of the feature "Pull Request", it's a request, not a demand. That's marketing-speak. It is absolutely a demand. PRs are a growth-hacking feature and are part of how GitHub got to be so dominant. The abuse of social pressure calling someo…

> Here's the root of your misunderstanding. “Broken” is subjective, relative only to you. This is not a misunderstanding. I want to know what other people subjectively think is broken, and their proposed fixes. So, if I agree with them, I can opt to use their fixes. A lot of time the developer does not want to maintain the added complexity, or does not agree with architectural or design decisions by the contributor,…

> I want to know what other people subjectively think is broken

And I do not. In fact I don't want to hear from anyone who uses my software at all, in any way. My software is for me, not for you, and not for them. If you think it's broken, make your own that isn't.

Post reply on HN