Hacker News Reader

Comment by sferik | Hacker News Reader

The problem with this funding model is that it encourages fluff pull requests, such as this one: https://github.com/sferik/t/pull/138/files.

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.

View on HN

I don't know. I find gittip's model mostly rewards popular coders.

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.

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.

Not only that, Gittip's project pages allow funds to be distributed to the entire team. So even if you're not well-known, if your project is, you can still get some.

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.

People have an economic incentive to pick the low-hanging fruit, but eventually there will be none left.

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.

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.

This is getting ridiculous:

https://github.com/sferik/t/pull/142/files

https://github.com/sferik/t/pull/143/files

https://github.com/sferik/t/pull/144/files

Shameless.

It was to be expected.

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.

What if the merger were able to modify the tip amount?

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...

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!

Yep, that's what I was imagining. And perhaps projects would publish any guidelines they end up going by for what commits could be worth.

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.

The problem with that is it forces you to reject good commits by people who want more than you think the commit is worth.

I have submitted similar pull requests to open source projects with no financial incentive. I don't really see the problem, as long as it's judged to be a "legitimate" correction.

Reply on news.ycombinator.com