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.

Gittip is certainly going to help more popular coders at first. But that's true with any platform in its early growth phase.

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.

You don’t know that the PR was submitted with any knowledge of tip4commit. Would you accept the commit normally? Do you want the very existence of tip4commit to modify your project management? My advice: act as if tip4commit doesn’t exist; they’re just providing a service on the side which you shouldn’t need to worry about.

IMO if this commit is useful - accept it. It will reduce the next reward by only 1%. Sooner or later all the simple ways to get tips will exhaust. The project will be a bit closer to perfection. And maybe you will have one more happy developer.

Hey there, that last commit is mine. I won't be getting a tip for it, I just thought it was a nice change. The first thing I usually look for with a tool like this is how to install it, so I moved the Ruby installation steps down to the bottom so as not to bury what I thought was the important bit in the Installation section. Poorly-timed, if anything.

While I love to get documentation updates, the comma thing and semi-colon thing is ridiculous, and in the comma case is less correct in this context. The doc re-org isn't a bad thing, though.

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.

What if this kind of routine trivial fix is exactly the sort that needs to be incentivized to actually happen? This is perhaps an extreme example, but it's also the sort of thing that is both common and vaguely unappealing about open source projects. Everyone's excited to do the big important next feature or blatant bug fix, but no one really wants to do the janitorial cleanup.

Hm... Do you mean to allow the merger to specify the value of the commit? E. g. by default it could be 1%, but merger can make it smaller if commit is not very valuable. Sounds like a good idea, thanks!

Interesting idea. Here's a twist: what if the committer could set the value of their commit instead? Social pressure would dictate that most people would not overreach. Then those who make small but useful commits could recognize in advance their minor nature. This is essentially a kind of honour system.

That's actually a good idea; you'd probably get fairly reasonable results that way. The downside: using those tags at all makes it unambiguously clear that you care about the tip4commit tips.

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.