Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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.


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


> you just need to host public tarballs of your source code.

Except now I can do it all on one place.

> public repo = public/open PRs, because that's how a vcs works.

No it’s not. A PR is not a feature of git the vcs, it’s a feature of GitHub the website.

> other have the right to make community corrections

No, others have the ability. They are not an unalienable right to do so. Likewise they don’t have a right on my GitHub repo.

You keep falling back to “because they can, they have a right to”, which I think is obviously incorrect.

And I disagree that this is similar to notes on Twitter. It is comments on YouTube or replies on Twitter; they are by and large used by people to add their opinion on the topic.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: