> merely by posting code on github, we have now been conferred with the responsibility of "maintaining an open source project."
Well, yes, because by making the code available on Github and inviting issues and pull requests, you're saying "I'm maintaining an open source project."
> So what is it about posting code on the internet which mandates that people read, review...
Nothing, as you yourself point out later in your post:
> If the author had, instead of using github, simply posted a .tar.gz file on their personal home page, this wouldn't even be an issue
Exactly. This would have been a much better thing to do.
The point is that when you appear to be inviting contributions and someone spends their time and effort fixing a problem in your code, it creates a hostile environment when you then completely ignore these people.
The lack of information and feedback is what causes the problem and it's hardly onerous to at least provide a note saying something like, "This project is not actively maintained, but feel free to use it as a base for your own projects."
> because by making the code available on Github and inviting issues and pull requests
I may have missed something but where in the original article did he say he was _inviting issues and pull requests_?
The grandparent comment seems to be saying that hosting code on GitHub is not a tacit invitation for collaboration. It's OK to use it as a free central storage repository for projects where you're not interested in collaboration.
Also what about situations where an SVN repo is automatically mirrored to GitHub?
>"I may have missed something but where in the original article did he say he was _inviting issues and pull requests_?"
I think what the OP is saying is that by putting a project publicly on Github, and allowing people to submit issues/pull requests you're "inviting" it. I don't use Github, but I can guess that there is an option to "disable" those features, or at the very least keep the project private.
You can easily disable issues and either disable the wiki or make it editable only by project members, but there does not seem to be a way to disable or restrict pull requests.
> I may have missed something but where in the original article did he say he was _inviting issues and pull requests_?
It's right there on the Github project page. I don't know if Github has an option of disabling those things; it would perhaps be best if it did, but at the moment it - at the very least - implicitly invites participation.
As for other situations: is my suggestion of adding a note to the README.md problematic?
You cannot disable pull requests on Github. You can disable the issue tracker. You could however put something in the summary shown at the top of the page that you will likely not accept pull requests.
Well, yes, because by making the code available on Github and inviting issues and pull requests, you're saying "I'm maintaining an open source project."
> So what is it about posting code on the internet which mandates that people read, review...
Nothing, as you yourself point out later in your post:
> If the author had, instead of using github, simply posted a .tar.gz file on their personal home page, this wouldn't even be an issue
Exactly. This would have been a much better thing to do.
The point is that when you appear to be inviting contributions and someone spends their time and effort fixing a problem in your code, it creates a hostile environment when you then completely ignore these people.
The lack of information and feedback is what causes the problem and it's hardly onerous to at least provide a note saying something like, "This project is not actively maintained, but feel free to use it as a base for your own projects."