Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub discusses giving maintainers control to disable PRs

github.com

Post reply on HN
Print view View original

61–70 of 75 posts

Re: GitHub discusses giving maintainers control to disable PRs

#61

Post by _aavaa_ »

notepad0x90 wrote: post #51
vdqtp3 wrote: 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…

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

Nothing is stopping them from doing that. But they are not entitled to do it on my repo.

Re: GitHub discusses giving maintainers control to disable PRs

#62

Post by notepad0x90 »

Lammy wrote: post #59
notepad0x90 wrote: post #57

Earlier quoted context omitted.

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

Joke's not on me, that's exactly what I was suggesting. you win! and I agree with that bot as a solution.

Keep your code private if that's your attitude though. You don't want to share your code, you just want free advertisement.

You know what, you wrote your code, you didn't write github, you don't own github and you don't own the interaction github users have regarding public projects.

PRs are not your software. What you need to do is maintain a private git repo, or just make the repo private and post tarballs and builds on the releases page. that will solve the problem even better for you. you'll still be publishing source as well as executables that way. PRs are about github, it's users and their interaction with projects. When you give someone access to a repo, you can't complain when they create a feature branch and request a merge, that's all a PR is. In your case, you want to give people access to source code but not a repository, so do just that and leave people who want to publish a repository alone, or restrict access to your repo to a github organization with people you approve of to make contributions to private repos.

Re: GitHub discusses giving maintainers control to disable PRs

#63

Post by notepad0x90 »

_aavaa_ wrote: post #61
notepad0x90 wrote: post #51

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…

> 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. Nothing is stopping them from doing that. But they are not entitled to do it on my repo.

It is not on your repo, that's the confusion in this thread. PRs have not made it to your repo yet, you're not entitled to them. It's regarding your repo, but it is not a change or an activity that's made it into your repo. It's people who have checked out a branch on their repo, PRs are a way for those people to publish the changes in their version of your repo -- their version.

What you guys are suggesting on this thread is to prohibit people who gained access to your repo as a result of you making it public (not just the zip/tarball of the code, but the repo) from linking the changes they made in their repo to the original parent repo. They're requesting you merge their changes, but not demanding, and you can ignore them. but that request and linkage helps your users, who are already not being supported by you or given any warrantly of usability of functionality by anyone at all. You're making something available to people and making it harder for them to support each other and fix the software on their own.

Re: GitHub discusses giving maintainers control to disable PRs

#64

Post by notepad0x90 »

Lammy wrote: post #60
notepad0x90 wrote: post #58

Earlier quoted context omitted.

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

If your software is only for you, keep it private. Period.

When you make it public, the public have the right to fix it and share their fixes with each other. They can do it on another repo, but they discovered the code through your repo, so the easiest way is by linking it to your repo. If you don't want to hear from people at all, just publish the source without giving anyone access to the repo, or send notifications to junk folder, or use a lockdown bot like in the other post, host it on your own server and publish it on your own site, the solutions for you are endless. For the public, which you've exposed your software to, not so much. and that's the problem.

You should understand that this line of thinking is exactly why everyone is trying to require developers to identify themselves, sign their code,etc... We're depending on software too much to be tolerant of willful sabotage and reckless endangerment (e.g.: security patches).

Re: GitHub discusses giving maintainers control to disable PRs

#65

Post by Lammy »

notepad0x90 wrote: post #62
Lammy wrote: post #59

Earlier quoted context omitted.

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

Joke's not on me, that's exactly what I was suggesting. you win! and I agree with that bot as a solution. Keep your code private if that's your attitude though. You don't want to share your code, you just want free advertisement. You know what, you wrote your code, you didn't write github, you don't own github and you don't own the interaction github users have regarding public projects. PRs are not your software. Wh…

> Keep your code private if that's your attitude though. You don't want to share your code, you just want free advertisement.

There is no money nor mindshare to be had, so advertising is the entirely wrong way to think about it. This is a thought-process warped by the commercial sector. Even if somebody doesn't use my code they are still welcome to learn from it. They're welcome to use it, too, I just don't want to know about it :)

Re: GitHub discusses giving maintainers control to disable PRs

#66

Post by Lammy »

notepad0x90 wrote: post #64
Lammy wrote: post #60

Earlier quoted context omitted.

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

If your software is only for you, keep it private. Period. When you make it public, the public have the right to fix it and share their fixes with each other. They can do it on another repo, but they discovered the code through your repo, so the easiest way is by linking it to your repo. If you don't want to hear from people at all, just publish the source without giving anyone access to the repo, or send notificatio…

“everyone” lmfao

Re: GitHub discusses giving maintainers control to disable PRs

#67

Post by _aavaa_ »

notepad0x90 wrote: post #63
_aavaa_ wrote: post #61

Earlier quoted context omitted.

> 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. Nothing is stopping them from doing that. But they are not entitled to do it on my repo.

It is not on your repo, that's the confusion in this thread. PRs have not made it to your repo yet, you're not entitled to them. It's regarding your repo, but it is not a change or an activity that's made it into your repo. It's people who have checked out a branch on their repo, PRs are a way for those people to publish the changes in their version of your repo -- their version. What you guys are suggesting on this…

There is no confusion about that. I think the confusion is repo being used for both 1) the actual remote git repo hosted by GitHub and 2) the “repo” at GitHub.com/username/project.

I know that opening a PR does not affect the first, but it very much affects the second. For my project both are mine, and just as I have the right to ignore a PR and I have the right to reject any after they’re opened, so too do I have the right to reject PRs before they’re opened.

> their version

And they can keep doing that without cluttering my page.

> what you guys are suggesting…

So what? Who or what states they are entitled to have their changes visible as a request on my repo?

Having publicly accessible issue and PR pages opens breeds the kind of entitlement you are showing here: they do not have a right to open requests on my page any more than people have a “right” to comment on a blog post or a YouTube video. And keeping an issue/PR section available leads people to assume that they have a right to do it simply because they can.

Re: GitHub discusses giving maintainers control to disable PRs

#68

Post by notepad0x90 »

Lammy wrote: post #65
notepad0x90 wrote: post #62

Earlier quoted context omitted.

Joke's not on me, that's exactly what I was suggesting. you win! and I agree with that bot as a solution. Keep your code private if that's your attitude though. You don't want to share your code, you just want free advertisement. You know what, you wrote your code, you didn't write github, you don't own github and you don't own the interaction github users have regarding public projects. PRs are not your software. Wh…

> Keep your code private if that's your attitude though. You don't want to share your code, you just want free advertisement. There is no money nor mindshare to be had, so advertising is the entirely wrong way to think about it. This is a thought-process warped by the commercial sector. Even if somebody doesn't use my code they are still welcome to learn from it. They're welcome to use it, too, I just don't want to k…

Fair enough. But I go back to my point that you can share source code without hosting a repository and a version control system. version control systems are intended to facilitate collaboration on code, and their exposure implies the intended audience that would perform such collaboration. Making it private shows that collaboration isn't a public affair. You can have a public repo that only hosts releases, or just host releases on your website.

Re: GitHub discusses giving maintainers control to disable PRs

#69

Post by notepad0x90 »

_aavaa_ wrote: post #67
notepad0x90 wrote: post #63

Earlier quoted context omitted.

It is not on your repo, that's the confusion in this thread. PRs have not made it to your repo yet, you're not entitled to them. It's regarding your repo, but it is not a change or an activity that's made it into your repo. It's people who have checked out a branch on their repo, PRs are a way for those people to publish the changes in their version of your repo -- their version. What you guys are suggesting on this…

There is no confusion about that. I think the confusion is repo being used for both 1) the actual remote git repo hosted by GitHub and 2) the “repo” at GitHub.com/username/project. I know that opening a PR does not affect the first, but it very much affects the second. For my project both are mine, and just as I have the right to ignore a PR and I have the right to reject any after they’re opened, so too do I have th…

> So what? Who or what states they are entitled to have their changes visible as a request on my repo?

You did, by making the repo public. You didn't make a release tarball public, you made git repository, designed for collaborating on code changes public. In this case, other users of github (including the general public) are exposed to a repository and all that entails. If you have no intention to let others do PRs, you don't need to host a public repository, you just need to host public tarballs of your source code.

> they do not have a right to open requests on my page any more than people have a “right” to comment on a blog post or a YouTube video.

Youtube videos are one-way consumption of media. Git repositories have the concept of merging, which is taking remote repository content and assimilating it with your repo (as you know), that's PRs. public repo = public/open PRs, because that's how a vcs works. You're not hosting a social media content on Github, you're hosting a public version control system, and you have the ability to make it private.

Youtube is hardly a good analogy, perhaps twitter or blue sky is, although even then it's consumed content, not collaboration. In that example though, what you all are proposing here is similar to tweeting but turning off the ability to get "noted" by the community. You have the right to say whatever you want (within the site's policy), but others also have the right to make community corrections (notes) so you won't mislead others.

Re: GitHub discusses giving maintainers control to disable PRs

#70

Post by notepad0x90 »

Lammy wrote: post #66
notepad0x90 wrote: post #64

Earlier quoted context omitted.

If your software is only for you, keep it private. Period. When you make it public, the public have the right to fix it and share their fixes with each other. They can do it on another repo, but they discovered the code through your repo, so the easiest way is by linking it to your repo. If you don't want to hear from people at all, just publish the source without giving anyone access to the repo, or send notificatio…

“everyone” lmfao

fair criticism, everyone not in tech then. I meant governments and corporations though, it wasn't meant in the strictest sense obviously.
Post reply on HN