I don't get why he doesn't like Pull Requests on GitHub. It obviously depends on the kind of mailing list software you use, but most of them (like shudder GNU Mailman) strongly discourage the user to hunt for existing requests and make pretty much everything hard to follow except if you follow everything all the time. Of course, if you're a maintainer, it's your job to follow almost everything all the time. But casual contributors simply don't have that kind of time and energy available.
With PRs on GitHub, a corresponding issue is usually filed and if people still email you, simply tell them to first search there and then post their own. That way, everybody can see and search the existing stack quickly.
I recently tried to contribute to a project that maintains both a mailman mailing list (I offer a thousand internets to somebody who builds a general purpose and usable UI to that) and a GitHub tracker and it was an absolute nightmare to coordinate.
Because they don't go to the mailing list. For a lot of OSS communities, if it didn't happen on the list, it didn't happen. That's certainly how it is in all the big projects I've interacted with. I'd LOVE for a way to cc a mailing list on all PRs to a project, but that's not possible AFAIK.
Most PRs I reject with "this should be a patch sent to the list" simply because I'm not always the only one that should review something.
> For a lot of OSS communities, if it didn't happen on the list, it didn't happen.
Yeah, well, maybe that's a bad idea?
There is another big FOSS project I know which has its own bug tracker from way back when (horribly outdated, frequently malfunctioning, terrible usability) and then they have their new GitHub tracker. The result? If you want to file anything, you have to file it in both systems.
What I'm trying to say is: You have to make a choice at some point. Either you move forward and solve problems, or you stay where you are. But don't blame the move forward for not allowing you to stay where you are.
With PRs on GitHub, a corresponding issue is usually filed and if people still email you, simply tell them to first search there and then post their own. That way, everybody can see and search the existing stack quickly.
I recently tried to contribute to a project that maintains both a mailman mailing list (I offer a thousand internets to somebody who builds a general purpose and usable UI to that) and a GitHub tracker and it was an absolute nightmare to coordinate.