Hacker News Reader

Comment by diggan | Hacker News Reader

How do you deal with the issue that "more pull-requests" does not equal "better project"? My concern is that getting paid per PR does not address two things. The first is that if you have a two bugfixes that are closely related, you still incentivised to split it up just because that's how you get paid. The second one, how to deal with long-term projects? Because the more PRs I make, I can just make shitty work so I have more work to do in the future. I'm not concerned about the long-term of the project, only that I can get in as many PRs as possible.

View on HN

I actually think "more PRs" usually does mean "better project" in the sense that smaller PRs are easier to review and reason about than larger ones. To me, though, I think the incentive here goes the other way - I'd want to put everything in one big PR so it looks like my client is getting a lot of work for their money. Either way, it's hard to imaging tying payments to PRs not having some impact on the coding process, which seems like a negative thing to me.

How the PR's are broken up is ultimately at the discretion of the developer.

You could make small PR's into a feature branch and have those reviewed. At the end, you can then tag the big PR for payout.

Thanks for the feedback and great question here.

PRs are still attached to an hourly or flat rate that you and the client have agreed upon. This means you will not make more money for submitting more PRs. You just receive your payments sooner.

The client also approves your pull request to trigger the payout. The minute your code is accepted into their codebase you receive payment.

I'd love to hear more thoughts on your concern here and if this solves it, really great insight.

Would love to hear your comments on my second point as well. How does this not ruin long-term prospects of projects?

The payouts are issued on PR approval, which has mitigated the spamming of low quality work.

> I'm not concerned about the long-term of the project

You're right. With TrapFi, we try to fix this with a high degree of transparency regarding the quality of work that the developer is charging the client for.

> With TrapFi, we try to fix this with a high degree of transparency regarding the quality of work that the developer is charging the client for.

This sounds a bit ominous — you do what exactly to create a high degree of transparency?

We simply link to the pull requests in the client's bill. Also, a repo admin can review the work before a payment is issued.

Reply on news.ycombinator.com