-
Notifications
You must be signed in to change notification settings - Fork 59
O>reward for results rather than effort #318
Comments
+1 for results. I'm all about results. |
@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. |
yeah, totally agree with this suggestion! @Viraculous writes:
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:
|
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...
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:
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). |
$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. :-) |
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.
|
@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 😕 |
@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. |
@David405 point me to one or two examples comments that required hours of study and research? |
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. |
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. |
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. |
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:
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 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:
#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.
The text was updated successfully, but these errors were encountered: