4 ms·

I think you'd need to define the value of contributions before you ever begin. Otherwise, time will be spent bickering of the value of work, and not actually do

by synnik 17y ago

I think you'd need to define the value of contributions before you ever begin. Otherwise, time will be spent bickering of the value of work, and not actually doing the work.

pudo 17y ago
True. Also, having quantified the value of each contribution might actually create a disincentive for joining the project: that 5-line patch that was going to be my very first contribution is now officially worth nothing, so why submit it? By laying a focus on the top contributors instead of the new/potential ones, this undermines the crucial ability of F/OSS projects to motivate people to _gradually_ extend their involvement.
- ErrantX 17y ago
  Yeh sold. :) The embryo for this grew out of wanting to try and make those 5 patch contributions worth something tangible and to encourage them... sadly it seems the idea just got lost along the way and does the opposite. Back to the drawing board :D
  - dflock 17y ago
    Maybe you could weight contributions differently, depending on what kind of behavior you want to encourage? For example you could make first contributions worth double, or have first contributions gain a bonus of x shares, which they can cash in/withdraw after their 5th/nth contribution, or something?
    - sp332 17y ago
      That encourages new-account spam. Maybe you could make them wait, like a "signing bonus", for a month? or until their third contribution?
      - dflock 17y ago
        Yes, that's what I suggested, actually.
  - synnik 17y ago
    You might not have to go all the way back... I've thought of this concept before, and I think the key is to measure based on contributions to functional goals of the project, not amount of code added. For example, participating in a discussion on requirements for a specific function is worth X points. Submitting the code is worth X points, too. Documentation is worth X points, as is communicating with the end users who requested the function or found the bug. In short, reward people based on participating in a collaborative development process. Then that 5-line patch is more highly rewarded by someone who takes ownership and truly participates, not just a random coder with time to spare. Might this discourage some people? Yes... but only people who wouldn't have time or inclination to be significant participants in the project anyway. In the long run, the team and project should be stronger. At least, I thi/hope so...

by synnik 17y ago

I think you'd need to define the value of contributions before you ever begin. Otherwise, time will be spent bickering of the value of work, and not actually doing the work.

pudo 17y ago

True. Also, having quantified the value of each contribution might actually create a disincentive for joining the project: that 5-line patch that was going to be my very first contribution is now officially worth nothing, so why submit it? By laying a focus on the top contributors instead of the new/potential ones, this undermines the crucial ability of F/OSS projects to motivate people to _gradually_ extend their involvement.

ErrantX 17y ago
Yeh sold. :) The embryo for this grew out of wanting to try and make those 5 patch contributions worth something tangible and to encourage them... sadly it seems the idea just got lost along the way and does the opposite. Back to the drawing board :D
- dflock 17y ago
  Maybe you could weight contributions differently, depending on what kind of behavior you want to encourage? For example you could make first contributions worth double, or have first contributions gain a bonus of x shares, which they can cash in/withdraw after their 5th/nth contribution, or something?
  - sp332 17y ago
    That encourages new-account spam. Maybe you could make them wait, like a "signing bonus", for a month? or until their third contribution?
    - dflock 17y ago
      Yes, that's what I suggested, actually.
- synnik 17y ago
  You might not have to go all the way back... I've thought of this concept before, and I think the key is to measure based on contributions to functional goals of the project, not amount of code added. For example, participating in a discussion on requirements for a specific function is worth X points. Submitting the code is worth X points, too. Documentation is worth X points, as is communicating with the end users who requested the function or found the bug. In short, reward people based on participating in a collaborative development process. Then that 5-line patch is more highly rewarded by someone who takes ownership and truly participates, not just a random coder with time to spare. Might this discourage some people? Yes... but only people who wouldn't have time or inclination to be significant participants in the project anyway. In the long run, the team and project should be stronger. At least, I thi/hope so...