There is a sense of pressure to merge PRs, though. When you have a lot of open PRs it starts to discourage further contributions. And if you reject a lot of PRs, or if you are too strict about it (i.e. nit-picking their PRs) it can also create a negative atmosphere that discourages further contributions.
Also... when you deal with dependencies in a package manager (like npm dependencies), it is less than ideal to rely on a GitHub fork rather than the module itself.
Personally, I try to merge PRs as often as possible. I aim to keep my open PR count at 0.
If a PR is not quite right (which is often the case), I will clone their fork locally, and edit their commit(s) using git rebase and then merge it.
That way the user is still acknowledged as a contributor on GitHub (and they can see both of our names/profile pictures next to the commit message). Then I make a comment explaining why I edited their commit(s) on the pull request itself or the issue page. That keeps everyone happy and encourages further contribution.
It's not always practical to do this though but it feels natural in many cases.
So quickly outline the reason why it's not ready for merge, and if the contributor doesn't respond in a reasonable window you can reject the PR with a clear conscience. If someone else takes an interest and offers to clean up the code, you can reopen the PR.
Comments
There is a sense of pressure to merge PRs, though. When you have a lot of open PRs it starts to discourage further contributions. And if you reject a lot of PRs, or if you are too strict about it (i.e. nit-picking their PRs) it can also create a negative atmosphere that discourages further contributions.
Also... when you deal with dependencies in a package manager (like npm dependencies), it is less than ideal to rely on a GitHub fork rather than the module itself.
Personally, I try to merge PRs as often as possible. I aim to keep my open PR count at 0.
If a PR is not quite right (which is often the case), I will clone their fork locally, and edit their commit(s) using git rebase and then merge it.
That way the user is still acknowledged as a contributor on GitHub (and they can see both of our names/profile pictures next to the commit message). Then I make a comment explaining why I edited their commit(s) on the pull request itself or the issue page. That keeps everyone happy and encourages further contribution.
It's not always practical to do this though but it feels natural in many cases.
So quickly outline the reason why it's not ready for merge, and if the contributor doesn't respond in a reasonable window you can reject the PR with a clear conscience. If someone else takes an interest and offers to clean up the code, you can reopen the PR.