Phyx
I dislike this approach, having to already deal with a project that does patches via mailing lists it is very hard to follow conversations. As soon as multiple people get involved things fall apart.
I think accepting pull requests via GitHub can be done with minimal involvement from existing contributors. All we need is one or two people to keep an eye on the PR queue and merge or transition-to-Phabricator PRs as they arrive.
I have multiple mailing rules and other things just so I can keep track of comments. And then volume makes patches disappear into a void.
We already have a lightweight process. Lots of people just attach the patch to trac. And we still accept it.
Going to trac forces you to give me useful information about what you are trying to fix. A mailing list doesn't force a submitter to give me basic information about the patch. Such as which platform it effects.
A commit message as you are forced to provide by Git should usually be sufficient here. Of course, there are always cases where users will offer insufficient commit descriptions, but this is something that only the pull request monitors should need to worry about. Cheers, - Ben