O>reward for results rather than effort

[dckc]

I suggest, as a guideline, that we reward only completed work (i.e. closed issues) and base budgets on results rather than effort.

Putting emphasis on completed work and closed issues would encourage SMART objectives. If only part of an issue got done, the participants would have a choice between (a) waiting until a later month to claim a reward or (b) reducing the scope of an issue to what they actually achieved, with the option to open other issues for further work.

Background

I have asked for justification of some high budgets (#291, #266). In doing so, I suggested that such a high budget implied a large number of hours of work; this is based on some advice I saw from @lapin7 on 2018-01-28:

Indication for budget: Number of Hours that the issue takes; Multiply x hour rate of $40 = budget

Meanwhile, @MParlikar noted that the core team welcomes contributions from experienced scala developers, but it's not a good use of their time to train less experience developers on things they could be learning elsewhere (e.g. functional programming with scala, how to use git / github / jira). I took the ball to establish some norms in #273:

story points seems to be an important way to normalize things.

Story points are in some sense a measure of effort, but they are normalized to the work rate of the core dev team. Someone who takes more time to do some work than they would are not rewarded for going slower.

Regarding translation rules #302 @flowpoint writes:

1. if the result matters, then the goal and budget should be fixed. however someone got there isnt important.
   or
2. if the amount of effort matters, reward is proportional, then whether google translate was used impacts alot.

#284 shows we could use some clarity on what comments count for.

@pmoorman and I realized in discussion #261 that emphasizing closed issue could help with bad actors, too.

[MParlikar]

+1 for results. I'm all about results.

[Viraculous]

@dckc, accruals of rewards on budget based on accomplished task is a good check to dealing with bad actors but i consider it better that rewards are in proportion of the percentage of the work done. SMART participation is encouraged and highly important but considerations must be given to certain issues though important and useful, yet is indeterminate because it is affected by exogenous variables which goes beyond the organisational control.

[pmoorman]

yeah, totally agree with this suggestion!

@Viraculous writes:

i consider it better that rewards are in proportion of the percentage of the work done.

I think this doesn't need to necessarily conflict with what @dckc is suggesting, although it's complicated to execute this properly. Variations on the 90-90 rule hold true in many other areas of business.

It's much easier to stick with a binary done/not-done, and adjust the scope of an issue to fit around this constraint.

That's in line with what @dckc suggested when he wrote:

If only part of an issue got done, the participants would have a choice between (a) waiting until a later month to claim a reward or (b) reducing the scope of an issue to what they actually achieved, with the option to open other issues for further work.

[pmoorman]

Personally (as a guy who works mostly in direct-response marketing) I like results-based rewards for a few reasons, but the main one is that it's fair & transparent...

• High-impact performers will want to work in an environment where it's transparent and clear that their work is what made the difference (and get compensated accordingly)

• Below-average performers want to work in a bureaucratic environment were everyone gets "treated equally" which means they get a little more then they really should

The core values of RChain are openness and transparency. Transparency favours results-based rewards.

---

P.S. I'm taking things a little out of context maybe, but consider this quote from above:

Indication for budget: Number of Hours that the issue takes; Multiply x hour rate of $40 = budget

Pushed to it's logical conclusion, this approach means that anyone who's work is worth (significantly) more than $40/hour, shouldn't be working for RChain.

That means you scare away the high-impact people, and build an army of mediocracy. That's not our spirit (at all).

[lapin7]

$40/hour was based on an assumption that anybody on the planet could live with $6400/month. If you would get more then you do silly things. If you get less then you're hungry for more.

And $40/hour was meant just as an indication. Probably it's more convenient to express the urgency/importance of an issue in the height of the budget. We can also take into account the Return on an issue. There will be several measures to indicate a return.

And let's not make big uncontrollable issues. Issues have to be SMART. That means probably for Development work that it has to be split up in SMART issues. That could be just copies from the Jira project management.

Mind you. This issue/budget/reward/invoice/payment system is on a constant prototyping base. However every month it needs an output of rewards. The way we do that, can change every month.

For example the spreadsheet prototype will be soon obsolete, because of the size of the sheets. Luckily @dckc is working hard on a replacement prototype. :-)

[jimscarver]

Supporting the attention economy was a significant design requirement of rchain. The idea that a person's time is a scarce and finite resource and people should be rewarded for their attention is fundamental to the world rchain aims to enable, But a person's time is just one thing that should be rewarded. Budgets should cover time for both great and small contributions producing the work product. Rewarding engagement in cooperative activities is how we might enable cooperation at scale.

[pmoorman]

@lapin7 thanks for clarifying the $40/hour thing. It's also good you keep reminding people it's all still experimental!

I've been thinking yesterday that "result-based" isn't necessarily the same as "performance-based" as I had in mind.

Results-based as @dckc talked about it is mostly focused on getting paid when tasks are done, which it seems that most people here support.

The reward-based vs. performance-based is maybe an entirely different topic. So apologies for making things needlessly complicated there 😕

[David405]

@dckc, nice point you have here but I strongly believe that efforts such as comments and suggestions sometimes are just as much work as doing the main tasks since they require hours of study and research and so a little motivation or encouragement such as rewards is also fair.

[dckc]

@David405 point me to one or two examples comments that required hours of study and research?

[flowpoint]

we could make commenting/ suggestions/research/discussions discrete, meaning you have to make some kind of "paper"/ writeup on your knowledge and work, which is then reviewed, and based on quality, rewarded.
we need to define atleast a minimal work needed to get rewarded on comments, or else overhead gets out of hand.

[David405]

I can't begin to search and pinpoint which comments consumed a lot of time as that will be an unnecessary use of valuable time but trust me when I say the people here not just myself do a thorough research on issues before commenting, the time of research might not necessarily be in hours but takes it time. I know that soon you will see how relevant comments can be.

Please dont misquote me, I am not in anyway downplaying on how important doing the main task is, I know this is far more important and needed than comments but comments are also needed to get the job done.

[dckc]

If I spent hours on a comment, I'm pretty sure I would remember it and I could find it again.

I think we're reaching a point of diminishing returns in this discussion. I aim to see that only completed work is rewarded, but I'm not inclined to spend more time convincing others. It's only a guideline anyway; I don't aim to establish any sort of hard and fast rule.