If there was no financial incentive, I would probably merge it but now I'm questioning the motivations of the committer. If I merge this, it means there will be less money for someone else, who makes a more significant contribution in the future.
Personally, I prefer Gittip’s model to incentivize open-source contributions, if only because it doesn’t create this kind of noise for project maintainers.
Where as tip4commit, rewards are not influence by popularity. I do see how fluff pulls could drain the pool. One needs to ask: Is changing a typo worth $4 dollars? Is it worth my time to do it? Maybe I should just click that merge button.
In my opinion bountysource is the best reward system, as it gives context, popularity is a boon, and it shouldn't generate fluff.
Just my two cents.
When Gittip is more well-established, anyone who wants to should be able to put a "Gittip button" on their project page. When Gittip itself has more name recognition, an unknown coder who creates a widely-used project should be able to rapidly pick up meaningful support through Gittip.
Personally, I wouldn't mind accepting something like that for my own open source project. It takes time to proofread, and I appreciate spotless grammar.
But, I also suspect that once there are lots of projects that have this feature, and the maintainers establish that they won't merge non-useful commits, like grammar nitpickery (though good grammar has value, and we merge stuff that fixes grammar in our docs, and I wouldn't mind having people get paid for it) this would become less common. And, reputation still matters. I wouldn't want to be "that guy" (and I wouldn't want to hire that guy for substantial work) that takes advantage of a simplistic system to get paid.
A project could have a standard of, say, 0.5% for typo fixes, 1% for documentation, 2% for refactoring which improves Code Climate or coverage statistics...
One plausible possibility that might help: in the block that normally contains Signed-off-by and Reviewed-by, add a tag for marking a commit as "minor" or "trivial", in the sense used by the Linux kernel's trivial@ patches or the GNU project's threshold for changes accepted without copyright assignment.
And as a quick hack, scale the tip by log(diffstat) with a sensible upper bound.