Another issue is that github's "merge a pull request" system is completely broken.
Most projects on github, by virtue of being based on git, will have several branches within the repository. The regular contributors to the project will know branch 1 from branch 2 and will submit their PR's against the projects "dev" branch (whatever it happens to be).
But irregular contributors, or out of the blue contributors, will invariably choose a branch that is not the projects "dev" branch upon which to base their patch, and then submit their pull request.
And for the project receiving the pull request, the github "handle it" interface is all-or-nothing. You either put the patch in, against the branch the requester used, no matter how wrong that branch might have been, or you simply can't merge it via. github's web interface. And if you don't merge it by github's web interface, you can't mark it accepted. Your choices are "accept and merge patch" and "refuse".
So there's a very good chance that some number of those outstanding pull requests shown have actually been merged, but were merged by the maintainer pulling a patch out of github manually, and applying the change manually via git to the correct branch and not the branch the submitter picked. And since the patch was in fact merged, poking the github "refuse" button in the web interface would seem wrong, so the outstanding pull request just hangs around, forever, because github can't be told "I did merge this, just outside of your view".
Most projects on github, by virtue of being based on git, will have several branches within the repository. The regular contributors to the project will know branch 1 from branch 2 and will submit their PR's against the projects "dev" branch (whatever it happens to be).
But irregular contributors, or out of the blue contributors, will invariably choose a branch that is not the projects "dev" branch upon which to base their patch, and then submit their pull request.
And for the project receiving the pull request, the github "handle it" interface is all-or-nothing. You either put the patch in, against the branch the requester used, no matter how wrong that branch might have been, or you simply can't merge it via. github's web interface. And if you don't merge it by github's web interface, you can't mark it accepted. Your choices are "accept and merge patch" and "refuse".
So there's a very good chance that some number of those outstanding pull requests shown have actually been merged, but were merged by the maintainer pulling a patch out of github manually, and applying the change manually via git to the correct branch and not the branch the submitter picked. And since the patch was in fact merged, poking the github "refuse" button in the web interface would seem wrong, so the outstanding pull request just hangs around, forever, because github can't be told "I did merge this, just outside of your view".