Our hypothesis with this project is that any commit, even a "fluff commit," is better than no commit, and that the overhead of trying to build a more complex accounting model is higher than the cost of paying out 2% for "fluff." Basically, worse is better.
When I saw the fluff commits I was immediately reminded of a conclusion from "Punished By Rewards" - once a reward is applied, people will start doing the minimum required to obtain the reward, as their motivation has shifted from intrinsic ("I want to improve the project") to extrinsic ("I want a reward, so what do I have to do to get it").
I actually think your attitude is the right one to have for this kind of experiment. We can pontificate endlessly on what people might do, how people might exploit such a system, but I'm of the (possibly naive) opinion that just because a person can, doesn't mean a person will.
I suspect that, despite the potential for abuse, you won't actually see very much actual abuse.
Alternatively, it may influence commit behavior. People may not want to be accused of filing fluff commits & slow their contributions to accumulate 'enough' changes to justify the payout.
I hadn't thought about this... but honestly a simple solution would be to let the repo maintainer decide how much to give for each commit in a scale of importance.
You can't obviously measure it on number of lines changed or something because that doesn't reflect the importance of a change, but maybe just say "okay, I can merge this but you get only 0.0001% because it's just a minor typo" or something like that. And if somebody is trying to abuse the system then just give them 0.
A better way would be to set up issues with bounties (what is already mentioned in the article) so the actual developers can decide the worth of contributions before the contributions are actually made, in order not to do favoritism.
Why not let the person submitting the request set the value? All the maintainer would have to set is a cap, so no strange values slip by on accident. The value of specific issues and milestones could be determined as a function of the global cap.
Doesn't fix the problem. Actually makes it harder: I shouldn't have this level of management forced on me. Perhaps the repo owner (or whoever manages pull requests) should receive an amount? Obviously this could be abused too.
What do you mean? You are the repo owner and you set up issues with a specific value, then whoever submits a pull request (merged) for those issues automatically gets paid.
Or maybe I didn't properly understand how it works?
I was thinking more along of the lines of sferik's situation, where someone other than the repo owner funded the rewards. I certainly am not interested in paying anyone to improve any of my projects, but if any were valuable, a third party might.
Yeah, I think this has the intractable problem of effectively useless commits.
One might argue that initially those problems would fix themselves as people would grab for the lowly hanging fruit, and that's fine, but I could see someone refactoring segments of code for no realistic reason, but "selling" it as an improvement, for the explicit goal of collecting the money.
Having a gatekeeper prevents this somewhat, but this company seems more interested in some kind of idealistic anarchy.
Although to be honest, after the first few changes to readme/documentation[.] there really isn't much more left to update. And the actual maintainer of the repo has the final say on deciding what will and will not be pulled in. If you are just sending me lines upon lines of refactored code that literally does nothing but just move stuff around, I'm not going to merge it. Simple as that.
[.] Finally! We'll be having people fighting each other for a more up-to-date documentation!
Comments
My gut instinct was "this is perfect". However, sferik says it's made maintaining his repo much, much harder:
https://news.ycombinator.com/item?id=6882374
(SFErik had nothing to do with the bitcoin stuff; someone else put up the money and started it for his repo.)
Our hypothesis with this project is that any commit, even a "fluff commit," is better than no commit, and that the overhead of trying to build a more complex accounting model is higher than the cost of paying out 2% for "fluff." Basically, worse is better.
But, we could be wrong! We'll see.
When I saw the fluff commits I was immediately reminded of a conclusion from "Punished By Rewards" - once a reward is applied, people will start doing the minimum required to obtain the reward, as their motivation has shifted from intrinsic ("I want to improve the project") to extrinsic ("I want a reward, so what do I have to do to get it").
I actually think your attitude is the right one to have for this kind of experiment. We can pontificate endlessly on what people might do, how people might exploit such a system, but I'm of the (possibly naive) opinion that just because a person can, doesn't mean a person will.
I suspect that, despite the potential for abuse, you won't actually see very much actual abuse.
Alternatively, it may influence commit behavior. People may not want to be accused of filing fluff commits & slow their contributions to accumulate 'enough' changes to justify the payout.
We added a FREEBIE keyword today for commits that are small enough the author doesn't think they should get a reward.
I hadn't thought about this... but honestly a simple solution would be to let the repo maintainer decide how much to give for each commit in a scale of importance.
You can't obviously measure it on number of lines changed or something because that doesn't reflect the importance of a change, but maybe just say "okay, I can merge this but you get only 0.0001% because it's just a minor typo" or something like that. And if somebody is trying to abuse the system then just give them 0.
A better way would be to set up issues with bounties (what is already mentioned in the article) so the actual developers can decide the worth of contributions before the contributions are actually made, in order not to do favoritism.
Why not let the person submitting the request set the value? All the maintainer would have to set is a cap, so no strange values slip by on accident. The value of specific issues and milestones could be determined as a function of the global cap.
Doesn't fix the problem. Actually makes it harder: I shouldn't have this level of management forced on me. Perhaps the repo owner (or whoever manages pull requests) should receive an amount? Obviously this could be abused too.
What do you mean? You are the repo owner and you set up issues with a specific value, then whoever submits a pull request (merged) for those issues automatically gets paid.
Or maybe I didn't properly understand how it works?
I was thinking more along of the lines of sferik's situation, where someone other than the repo owner funded the rewards. I certainly am not interested in paying anyone to improve any of my projects, but if any were valuable, a third party might.
Yeah, I think this has the intractable problem of effectively useless commits.
One might argue that initially those problems would fix themselves as people would grab for the lowly hanging fruit, and that's fine, but I could see someone refactoring segments of code for no realistic reason, but "selling" it as an improvement, for the explicit goal of collecting the money.
Having a gatekeeper prevents this somewhat, but this company seems more interested in some kind of idealistic anarchy.
Although to be honest, after the first few changes to readme/documentation[.] there really isn't much more left to update. And the actual maintainer of the repo has the final say on deciding what will and will not be pulled in. If you are just sending me lines upon lines of refactored code that literally does nothing but just move stuff around, I'm not going to merge it. Simple as that.
[.] Finally! We'll be having people fighting each other for a more up-to-date documentation!