Contribution Reward ⭐️

[liviade]

Last week in soft gov we started to look at alternative contribution reward systems.

Praise has been working great (!) and I haven’t seen a more encompassing reward method so far (praise to @Griff for that). The problem is that every week, more and more work happens, more enthusiastic collaborators join and more praise is dished, what an awesome problem to have!

Here we face a few challenges:

1- Scalability: Every two weeks, praise is manually quantified by Griff and I, this process currently takes around 2 hours.

2- Automation: The cultural build impact hours will turn into vested TEC tokens right after the Hatch, but we don’t have a process for how the impact hours would be distributed as tokens once the Commons is running.

3- Centralization: Praise is subjectively quantified and there are a few barriers for this role to be easily rotative. The 2 or more people quantifying should be aware of mostly everyone participating and of everything happening in the system - otherwise we would need a barrier for who is allowed to dish to maximize trust, which may end on less important things being praised and we don’t want that.

@JessicaZartler started a document called Contributions, Rewards System & Roles Research & Ideas - We went over it on the last soft gov call and decided to experiment with SourceCred following 1hive steps towards a more automated system to co-exist with Praise.

In parallel to this investigation, Eli,Jonas and Dulce from the onboarding working group, started to think about a praise 2.0 or a credit system. They mapped an initial structure for how this would look like and left an open invitation for more brainstorming to happen!

Jump into this issue if you want to help the SourceCred implementation to move forward

And please add your thoughts to solutions for this praise dilemma

[liviade]

COMMENTS FROM FABIAN - from the “Contributions, Rewards System & Roles Research & Ideas” doc

I believe to establish what is praiseworthy is problematic, as you can never get it right, no matter how much effort you put into it, and thus its liable to upset people and getting gamed. Plus put unreasonable pressure on the people who evaluate what is praiseworthy, or how much.

1st: Use a Flattr based approach, where each individual has one voice, and can distribute points subjectively. a like universally for what is appreciated, or proportional distribution where one event may get 2 points and another 500. This is subjective among each individual, and it only matters about the final relative distribution. So if I distribute 10 single likes, everyone gets 10%, whereas if I put 500 points on a individual from a total of 1000, then that individual would enjoy 50% of my weight

2nd: Use relative distribution among peers, where one assigns a weight among their peers, as to who’s voice should count more. People who are heavily involved will likely enjoy more weight, based on how the community experiences this. This is essentially page-rank, where the weight of one who is highly recognized will enjoy a heavier weight in recognizing others, which might be appropriate.

3rd: to prevent sybill attacks, where one generates a 1000 accounts, there you can isolate clusters, if they aren’t valued by others and only ‘upvote’ or praise each other. This is more of a downstream concern, so for now its more of a placeholder, just so you know there is a way to deal with this, as things scale up and potentially distortion becomes more likely or possible, as it eventually is likely to attract more and more intention, and thus self-favouring behaviour needs to be immunized.

Just some thoughts based on the parts that I caught, and such a, ‘plus’ scheme would be quite simple, as its only about giving on or multiple likes, so its fairly intuitive and manageable, that’s why I advocate it. Plus it puts the evaluation in the hand of each individual in a manner which is delegating authority and responsibility (sovereignty) down to the indvidual who has a nervous system and is actually able to experience value

[liviade]

Quick Update:
@santigs and Mateo are going full power on the SourceCred implementation issue!!
Comments about their process are being added to Github https://github.com/TECommons/coordination/issues/37

[liviade]

@mateodaza and @santigs gifted us with a TEC SourceCred!

We discussed the next steps in our last Soft Gov call and to move forward we need a focused work session to:

• Decide the parameters from the initial baseline.

• Decide how and how much we are rewarding from praise and from SourceCred so there is no double rewards.

• Think of sanctions for abuse of the system and draft a social contract/conditions notice for everyone who joins.
• Explore BrightID implementation.

• Explore best ways to mix praise+ SourceCred
• Have a minimum viable solution to experiment for a few weeks before launching.

Are you reading this and feel the calling to schedule this worksession?
We are coordinating in this issue.
Please add comments/suggestions about the topics above

[Tonga]

i personally think sourcecred encourages a lot of “team play” for the rewards, and haven’t seen a clear solution to all possible scenarios, i like the praise system more evethough less people get to decide what’s worth and what’s not, i would like a system in which the people “dishing praise” can be voted on maybe, and also get rewarded just for deciding what’s worth a praise.
(i’m sorry i could make this post more organized and will if i find the time, but prefer to say something at least instead of nothing)

[santigs]

We will start testing SourceCrec after we have deployed our own instance.
We will be fetching activity from Discord, this forum, and Github, so we need some user’s handles to consolidate all three services activity into one account for each user.
We encourage those wanting to see how we test with SourceCred to provide us with their account names filling the corresponding cells of this spreadsheet

[cranders1]

done thnx @santigs @mateodaza

[eeli]

1. I think a hybrid approach has some advantages. I think the biggest potential pitfall from SourceCred is to dilute contributions with a lot of cred being minted from Discord. We already have a rich chat environment, and if we’re trying to use this to steer the community, I would say that this is certainly not a top priority.

2. I envision transitioning praise such that it is maintained on SourceCred. They themselves have a “props” system, which acts similar to praise. With more reactions and emojis, that contribution gets minted more cred. I feel strongly that our approach of having some rough measure of what contributions are worth is a better system for us. Upvotes or emojis should not scale the cred score, but scale the trust that it’s a legitimate contribution.

There’s a lot to unpack here, I just want to throw this out sooner than later.
As a quick example, Alice might be doing great work, but is shy and only connects with Bob. The fact that only Bob would upvote her contribution certainly does not mean it’s less valuable than someone else’s work that got 30x the upvotes because they are more connected.

[mateodaza]

Yes! There’s a lot of subjectivity so it’s really hard to automate the whole problem. I believe SourceCred will help a lot though, I love what you mention about scale the trust instead.

I believe time will allow us to know the middle ground on how to measure value the proper way for our particular problem.

[eeli]

I had a very exciting idea this morning for bridging TE’s praise system onto SourceCred, but want to get feedback before progressing any further:

The magic of TE’s praise system is that you can quantify the value (impact hours) of any contribution. The magic of SC is that it’s automated/scalable and slightly more decentralized, but it currently lacks the ability for communities to specify what’s valuable to them outside of the plugins (and the props channel, which can fall into popularity contest dynamics).

I was imagining a praise channel on discord where different emojis corresponded to different contribution types (impact hour tiers). Rather than mint more cred for popularity (number of reactions), the emojis would signal trust that this contribution is of a certain tier. To receive the cred of that tier, that post would need to receive some minimum trust.

In the example I gave previously, Alice’s great work only needs to be seen/praised by Bob, and then the rest of the community (if they trust Bob) can trust this.

(P.S. Yes, Sybil attacks, I know, but let’s brainstorm before going into problem solving mode.)

[mateodaza]

Love it! We could avoid sybil attacks by making a little human verification on the discord entrance, some other channels ask a simple math question for example. And after that I think we could use specific emojis for different kind of praise, no need to leave it only for a certain channel

Let’s keep discussing it!

[eeli]

Glad to hear that! It hit me that TE’s praise (intentionally or not) has been operating out of a brilliant scheme. Specifically, we can think of Liv and Griff as “super-trusted” community members. Because of this, we don’t need any complication cryptoeconomics for voting or attacks. I suggest that we set the trust threshold very low (2-3 votes) as long as they come from a select group of “super-trusted” users. We can progressively decentralize with more trusted users.

[santigs]

This is similar to the “Check In” channel 1hive had a couple of months ago. Basically every user who wanted was posting what they had done during the past day or days and the rest of the users if wanted added emojis. Initially is a good idea but I still see some potential issues:

• If a user forgets or just doesn’t post what he/she did in the channel, it will not get any reward.
• A user may post every single action and ask his/her friends to vote and get a lot of rewards

We would need to add additional checks as max votes per user per message or use some machine learning to try to fight users gaming the system. SourceCred is a great tool but there are many easy ways to game it. I believe we will have to test the tool for quite a while before even distributing any cred, so we can analyze behavior and set the initial parameters the best way.

[eeli]

Strongly agree that we certainly don’t want to follow in those footsteps. From your feedback, I think there are some low hanging things we could tweak that could make a major improvement on their model:

1. We could ditch self-reporting entirely and continue to only rely on praise (I think there’s utility in it’s ability to aggregate information across the system, but the concerns you brought up definitely outweigh missing a few contributions here and there).
2. Only trust from “super-trusted” users like Livia, Angela, Griff, etc. could count towards that post’s cred. (The SourceCred plugin has access to channel and user id’s, so we can know who reaction and with what emoji.) I suggest we be very stingy with trust, and very slowly expand the circle of trust outwards.

[liviade]

Based on our last Soft Gov call where @santigs shared Source Cred progress, two main questions came up to guide our next steps.

1. How do we want to reward what is being tracked by Source Cred?

• Distributing TEC tokens through the Source Cred instance?
• dishing praise to each person according to their Source Cred Score?
• Creating a template for people to request Source Cred rewards in the Commons?
• Please share other ideas

2. How can we understand as a collective what to use praise for and what is already being accounted by Source Cred?

[santigs]

One of the reasons to test SourceCred is to show up how the contribution is tracked in Github and this Forum. We are about to test the first distribution with fake tokens to see how contribution gets rewarded. I encourage you to check the data we will be sharing and post any questions you may have so everyone has a clear understanding of the way the system works before we all vote on when to implement it.

[ZeptimusQ]

I was thinking an interesting idea for the contributions acknowledged its to have an internal statistic of every WG and if it reflects the work done well, but if some WG is not dishing praise enough we would have that objective opinion

[ygg_anderson]

@ZeptimusQ - I love this idea. It’s like the UN’s SDG’s. Each WG gets a metric to optimize. Correlation analysis becomes available between sourcecred instances and increase in this metric (with a time lag).

Reference - SDG targets, metrics, and indicators:

UNSD SDGs API

[natesuits]

So, I just wanted to throw my thoughts into the mix about the subject of SourceCred.

Side-Note: @ygg_anderson…You sent me down the UN path…and I am extremely glad you did…I am really impressed with the approach the UN has taken with their SDG’s and specifically with the Public Administration Network structures. I cant believe I haven’t looked at the UN structure more closely. (I am attempting to write on the similarities/differences between The Public Administration Network and the Token Engineering Commons as two distinct approaches toward the creation of an Intellectual Commons)

Anyway, back to the subject of the Contribution Reward.

In my opinion, the purpose of the Contribution Reward is to reward members for the execution of functions within the TEC.

The use of SourceCred as an objective method for quantifying every individual contribution, big or small, is an extremely difficult task and one that has significant limitations as described by others above. I also think that attempting to build a perfect SourceCred system from the get-go is not important. It should be utilized in a way that works within our current setup, and achieves the functions it is designed to accomplish.

While every one of us who has commented on this post has provided value to the overall discourse of how we implement SourceCred, such recognition makes very little difference to the motivations of why we are here. Maybe one day in the future we will develop a system to quantify how much Cred is deserved between my post, and @ygganderson’s post, and between our collective posts and Santi actually developing it.

I had to ask myself, what is the difference between Cred and Praise, really?
And perhaps there are no differences. Except a language one.

Praise: There is a cultural value to the use of praise. It’s become an unusual and effective method for the cultural build of the TEC. I propose we maintain the use of of the term Praise even if we get rid of our current system of praise. (Cred=Praise)

Honestly I really like how cavalier we are with our use of praise. Praise Everything!!! I think this scales as well. Naturally, larger contributions and more quality contributions will on average receive more praise, while small contributions and broad ideas will receive less.

The act of praise should be universal and encouraged, and not restricted by excessive rules. The ability to game the system becomes rather difficult if we can create a system around it that incentivizes the creation of intrinsic motivations (around access rights) rather than extrinsic motivations (distribution of Grain) through the categorization of individuals holding Cred.

Example

We can have a Community Grain Distribution, where only a small amount of the Grain Budget is committed for general distribution.

Praise (Cred) Classes.
Holders with 100 - 500 praises (Cred) each share 10% of General Grain distribution
Holders with 500-1000 praises each share 20% of General Grain distribution
Holders with 1000 - 3000 praises each share 30% of General Grain distribution
Holders with 3000-6000 praises each share 40% of General Grain distribution

When classes become impacted, they can be restructured. As an additional benefit, we can integrate these classes of Cred earnings as a method for other forms of intrinsic motivation to be created.

Perhaps granting individuals with praise in a certain range the title of Steward, or Fellow, or Lead, etc…and whose titles come with unique responsibilities, access, and roles within the administrative structure of the TEC. Stewards can lead WG’s; Fellows can lead subWGs; Leads can participate in WG’s or serve on a Committee or a Task Force for example. (However the administrative structure is differentiated, you can grant special forms of authority/access over the work being executed within the TEC – all through a system of praise. There is also very little incentive to game this system.

Operating in parallel we can have a separate instance of SourceCred that rewards the execution of the goals and functions of the TEC. Where each working group assigns Cred allocations for each type of task, and members can execute on them, receiving a proportional amount of Grain when distribution occurs. This requires significant focus around planning/budgeting processes.

The administrative costs for the system is in fact the problem. Keeping track of praise via spreadsheet is troublesome. Automating this system should be the priority. The only solution I see is one that will require the integration of an identity system (I really like BrightID), but perhaps 3box may be a more pragmatic solution at the present – and of course the implementation of SourceCred itself.

Integrating Identification, and tokenizing praise is a big task…but like the development of any CPR Setting, we must be willing to fund the required infrastructures necessary for these things to exist. Is Praise worth maintaining…is it worth the cost of such development…I know it is.

By maintaining a system of praise, we offer a method for intrinsic motivation to be created through the opportunities granted by earning praise. The “objectiveness” of a single unit of praise is irrelevant in the aggregate if we establish norms and traditions around its use, and maintain the current attitude towards distributing it.

Of course my thoughts on this system are obviously post-hatch.

Annnnnywhoooo, those are me thoughts.

[liviade]

awesome insights Nate! thanks for sharing your thoughts. Yesterday @santigs @mateodaza and I had a great talk about the next steps for SourceCred and I also thought of how we could unite praise and cred. One of our biggest challenges now is the distribution post hatch. Many of the solutions we’ve come up with involve someone in charge of someone else’s rewards since one proposal can’t distribute to multiple addresses. This is a big fragility point. So I thought if we could use the SourceCred engine for distributing IH in the form of tokens it would be so great!

Now reading your Praise (Cred) Classes you’re suggesting an automated praise quantification right? I’m afraid cutting the manual quantification would kill the qualitative weight at all. Which is hard to exist without the human touch for now and could be easily gamified. What we could do is substitute praise for Impact Hours in your chart and distribute TEC tokens accordingly. I agree scaling the praise quantification is a big issue, but perhaps we can fractalize it instead of automating.

I’m curious how do you see the identity integration working?