Kudos Rewards - building the Status Meritocracy


#1

tl;dr - you might have heard in Jarrad’s Town Hall update today that we’d like to implement a system to allow contributors to recognize each others’ impact. Here’s a proposal for Kudos Rewards, we’re seeking your feedback.

What problem are we trying to solve?

We currently don’t have a consistent way to give recognition to other contributors, nor a way to have a transparent view on the contributors most recognised by our network. In the past, the Disco kudos bot in Slack served this function and helped people give spontaneous recognition, but that’s been missing since October 2018.

What’s the proposal?

Kudos Rewards - an experiment with awarding kudos each week between Status contributors. Heavily inspired by Giveth’s awesome RewardDAO concept, the idea is that contributors get a weekly allowance of SNT which they can distribute amongst other contributors as they see fit. The awarded totals can be withdrawn by contributors who have earned kudos (more on how that works later).

Why

  • Giving kudos allows us to recognise everyone making impactful contributions in the network. We value everyone’s contributions, and want to amplify achievements and give credit for all the great work going on
  • This concept replaces the Disco kudos bot, which was our last kudos system and was (overall) well-used and positively received
  • It’s inclusive of the whole community, everyone participating (not just core contributors) can be rewarded with tokens
  • It helps build a leaderboard/meritocracy over time, reflecting contributor impact and social capital.

How does it work?

  • V1 of this idea is smart contract based, and can be viewed [here](https://github.com/status-im/meritocracy (h/t @jarradhope) .
  • Weekly pings will be sent out by People Ops, directing everyone to access the DApp, view their allocated SNT, and award their tokens. You can award your tokens to any contributor(s) (core, occasional, anyone).
  • When giving out tokens, you can add praise along with your token reward so that the recipient knows what you’re awarding the tokens for.
  • After a certain date, each weekly cycle will be closed out, and contributors will no longer be able to make awards in that cycle. Any unused tokens (i.e. those that were allocated to a person but were not awarded onwards) are burnt at the end of each week (they can’t be carried forwards). No one is obliged to take part, and you can opt out from receiving tokens too if it’s not your thing.
  • Once a contributor’s allocation is reduced to 0 (either by awarding all their tokens onwards to other contributors, or having the remainder of their allocation burnt due to inactivity at the end of each week), they’re able to withdraw (claim) their reward tokens.
  • The DApp shows each contributor’s allocated, burnt, and awarded balances, i.e. participation stats, along with all the praise commentary they received.
  • Initially, core contributors will receive a flat weekly allocation. All contributors in the Statusphere can participate, by sending funds to the smart contract to signal participation. Contributed funds are allocated evenly across all contributors playing the game.
  • This basic first implementation can be iterated over time, e.g. this v1 will make use of admins to add contributors, manage weekly token calls etc., however in future as this evolves, admins can be phased out. The thinking is to start small with this idea and see how it works out.

What are the criteria for awarding tokens?

The aim is not to be prescriptive about what actions merit recognition. In the same way as you awarded kudos for any number of reasons in the past, a Reward Kudos can be given out however you see fit. That might be to recognise e.g. Impact, Helpfulness, Collaboration, Contribution to Status and the wider ecosystem, Principles, Quality of output, etc.

What is it not?

This is not a substitute for routine feedback-giving. We still think there’s value in giving qualitative on-the-job feedback to other contributors. This is about recognising positive contributions, but constructive feedback should also ideally happen too elsewhere.

There is also a limitation to be recognised here in that this can only tell us about visible successes. Someone who works in a less visible role, or with a smaller imprint across the network, would naturally maybe not receive as many tokens as someone in another role. As such, this would not make kudos outcomes a reliable single source of truth on contributor impact.

To begin with, it’s going to be a basic implementation to kick things off. We want to start strong with the ideal system in mind, so we’d love to hear your feedback on how you want to see this idea evolve.

Why now?

This is something that’s been on People Ops’s radar for a few months time in various forms or another, but hasn’t been a priority in recent months due to changes taking place. Now seems like a good time to re-initiate this discussion now that swarms are functional and Status is moving along smoothly.

Next steps

This is very much a v1 and is an experimental idea - nothing in this proposal is set in stone, but we’d like to give it a go to see how it goes and see how valuable people find it for recognising others.

If you have any ideas/feedback on improving this concept, feel free to share them. We’d love to collaborate with anyone interested in rolling out this idea, so if this sounds interesting, feel free to get involved (we don’t see this as a People Ops idea, giving recognition and rewards is something that benefits us all).

Please drop your thoughts here and (if this goes ahead) we’ll look to open the first weekly kudos round by mid-Feb.

Cheers! Ceri & JB


It's kudos o'clock
#2

My first SNT kudos will go to @jarradhope for building this over the weekend!


#3

My first SNT kudos will go to @jarradhope for building the kudos extension over the week! :smiley:


#4

Kudos to Ceri & JB for kicking this off :clap:


#5

I’ve been tinkering with some designs to see what this DApp might look like. Definitely needs a lot more work though:) See comments by the design team.

https://www.figma.com/file/SpOzKYfIb3x7HEGPLSC0x16b/Status-Meritocracy-HB?node-id=2%3A205

Still needs transaction flow included, a more detailed way of adding selecting contributors, etc. Will share back here when it’s in a more detailed shape to discuss:)


#6

Nice!
Have you considered a simple design for a kudos extension? :slight_smile:


#7

@julien is there an extension started for this? We could potentially spec it out clearly and then put a bounty/challenge on it as part of the extensions campaign we are going to pushing out over the next few weeks.

This could be perfect to have people dive into the work. How best can we go about having that created?


#8

@maciej pointed this out and will definitely look into that! Could be a combination of Extension for Rewarding and DApp for viewing and Admin.

Especially now that extension bounties are taking off and I’m reading Jonny’s response on an upcoming campaign.


#9

Whaaa :heart_eyes: so cool to see this come to life - thank you! :raised_hands:t2:


#10

No nothing has been started yet. I guess a simple mockups or ideas and details about the contract would be sufficient.
And someone motivated enough to fight with extensions! :sweat_smile:


#11

There’s some hurdles with extensions, I think if /send and /request could be implemented as extensions then Kudos could be as well. This should be done before EthCC imo.

For the command, I was hoping to do

  • above command text area = display allocation, received, withdraw button (and allocate button? (might be better in dapp only))

then /kudos 500 “<contact>” <praise>


#12

I just saw this, super fly!


#13

@jarradhope You can find a WIP version here. A good basis to try things :slight_smile: Note that it requires changes to be merged.

Is the contract deployed on mainnet yet?


#14

Signup here by 14th Feb with your name and wallet address if you’d like to participate :slight_smile: Cheers!


#15

Required changes have now been merged.


#16

@jarradhope Is the kudos contract deployed on some network?


#17

Contract is deployed at ropsten:
https://ropsten.etherscan.io/address/0x55F921Bb3318FfA68C1B4d69092bBaA31c0b0A62


#18

I deployed the current version of the meritocracy dapp in Ropsten: https://ipfs.infura.io/ipfs/QmSrbxiJvjYLMxMGitb9TywyxHMrHBzooEpvu5BbgqSnmE/
every contributor should have ~40 STT available to play with.

It’s probably missing some validations as well as lacking activity indicators but that will come once the design is applied


#19

awesome thanks for taking on the meritocracy and final bugs I was having with Embark/Metamask! what was the issue?


#21

In the case of Metamask, it might have been a combination of things. To avoid any possible web3 issue, the changes I made were:

  1. Verify network. Current Embark version publishes DApps that are associated to a specific network (i.e.: a dApp that’s published for Mainnet can only be used with a provider connected to Mainnet, compared to some dApps that can detect to which network you’re connected and use the contract addresses corresponding to that network)… so I added a warning in case the web3 provider is connected to a different network than the one the dApp expects. I know this is going to be solved in future versions of Embark.
  2. For all interactions with contracts, I added an explicit ‘from: web3.eth.defaultAccount’ as well as estimating gas costs before publishing a transaction.

After doing these changes, the dApp could successfully be used with Metamask

In the PR you can see I made some additional updates based on the //TODO comments you added to the sourcecode, but I believe the tasks mentioned before were the only things missing for fixing the issues you were having.