[libre-riscv-dev] Contribution measuring (not trying to start a war)

[Adam Van Ymeren]

On 2020-03-03 1:32 a.m., Jacob Lifshay wrote:
> I was wondering what benchmarks would we use to determine how much each of
> us has contributed for when Libre-SOC is more monetarily successful and
> someone wants to sell stock or determine how much of the profits they get?
>
> I think we should try to come up with something reasonable, maybe some
> combination of lines of code (sloc?), a difficulty factor (preferably
> estimated by others), and an importance factor (so algebraics would have
> lower importance compared to the 6600-style issue logic) and some
> additional terms for non-code contributions?
>
> The idea is to be as transparent and fair as possible, without spending
> unreasonable amounts of time calculating contributions.

So here's an idea I've been thinking about for how to split
profits/revenue for a small business.  Once a month or once a quarter
even, everyone does a sort of "peer review" where you assign everyone
else in the project a percentage of how much you feel their work
contributed to the current revenue stream.  You don't assign anything to
yourself, and your totals have to add up to 100.

Then average and normalize all the percentages that everyone received
from their peers to find a final percentage ranking of every member. 
Then everyone is awarded their percentage of the revenue/profit stream
until the next ranking.

By not ranking yourself you are forced to acknowledge and think solely
about other's contributions.  It also incentivizes collaboration, you
want your work to assist others in the project so they are more likely
to award you a bigger slice.

Downsides of this approach are that its very subjective, and could be
vulnerable to "politicking" where you are more incentivized to chit-chat
and convince people of your value rather than actually contribute value.

However most objective measurements such as number of tickets, lines of
code, "story points," etc are often easy to game and create perverse
incentives for contributors.  Lines of code for instance incentivized
writing more code rather spending time on architecture, design and
refactoring, which can lead to massive unmaintainable codebases. 
Issues/tickets incentivizes focusing on low priority tasks or gaming the
issue severity/importance system, which can lead to the more important
and more difficult issues never being resolved.  In general most
objective measurements create incentives that do not align with the long
term success of the business.

I don't think this such a rating system would scale well beyond 8-10
people, but that's in line with the unanimous decision making approach,
and there may be a way to apply divide and conquer here as well.

So far I haven't had a chance to try it and there some finer details to
iron out, but I really think something like this has potential to be
equitable, adaptable to all types of contributions and relatively low
effort.