Outlining the Rewards System Process.. v2!

(:point_up_2: Are some of these people Trusted seeds?:thinking:)

This could be great for continuity and to have a pool of more people as to not run into burnouts.

I overheard @Griff speak to there being an element of importance to the quantifiers being able to know who is doing what work as it supports continuity. I couldn’t agree more about the continuity part. The best database you have in a decentralized group is eachother. Teaching people to be aware of their surroundings is how information can be collected and shared. Common language is a piece too.

I appreciate the context I gain from reading Praise. I personally read every props and did-a-thing in my communities server. That’s where a majority of the deliverables go. I learn what’s happening and as time goes on I learn the people associated with the working groups too. After testing this process out in over a dozen servers I can say that It’s possible to read those without names/faces attached and eventually be able to know who is being spoken of. The dots will get connected on the video calls when people are giving updates (I don’t recognize faces much which is why I know this works i’m never tracking faces to contributions rather behavior.)

I’m appreciating the anonymous aliases. Anonymity has been brought up on a few occasions by many people over the span of sourcecred and even recently it’s resurfaced I like the idea because it sounds like it would make more people engage with it.

Quantification Parameters Appendix


  • Does anything happen for reviews?
  • Does anything happen if someone links a fix / closes out an issue within their pull request?

From a developers point of view are these things part of a first buildout or do they come in later on down the road?

It’s so rad to be able to see an instance be built with more intention of the behavioral impacts.

1 Like

My vision for this pool of Quantifiers is to have a very low barrier for entry. Really I only see 3 requirements to opt-in to be a Quantifier:

  1. Are Human.
  2. Know WTF the TEC is.
  3. Have read some sort of onboarding document, like the Rules of Praise that Livi is working on.

The bigger the pool and the greater variety of Quantifiers we get I think will help us achieve less subjective praise and also creates a new engagement tool for newcomers.


Those are some solid parameters. :joy: I was hoping the pooling was huge! It’s so good for people to be witnessing all the good happening around them. I dig that the bar to entry is low.

1 Like

Great point! Do you think the benefit of knowing who did what is greater than the bias that can come with it? The reason we thought about hiding the names of who was praised during quantification is to try to get a more approximate value of the contribution per se, rather than having that value attached and influenced by the persona.
Some people will still know who did what intuitively but I believe it plays a role in the psychology of the quant to not see the name immediately there.


Formula for the “Total hours”(net amount of tokens distributed in a Quant period)

From my current understanding of the mint process, we might be allocating a fixed percentage of the commons pool to the funding for the rewards distributed by Rewards DAO.
I’m wondering if it would be of any value to somehow make the total “hours” distributed or total funds distributed a function of no. of members that were praised, arbitrary “effort” metric that the quantifiers decide each quant(which represents how productive they felt the community as a whole for that period), changes to our economy and the relative success of the project(or relative to the funds available in the commons pool, in DAI) ?

My responses are from a vantage of earning through sourcecred, considering praise and taking into mind that the commons has different cultural practices for appreciating people than sourcecred’s community does. (our cultural practices around gratitude are timid, not radical)

No I don’t.

There’s a personal bias within me not minding the transparency, it gives myself and others an opportunity to practice gratitude for someone’s energy expelled (i come from the military, we have practices for noticing and honoring and mentoring and collaborating shadow does not manifest in the same ways there as it does out here with resource scarcity on the horizon for so many)

As I’m thinking this through I would be foolish not to think about how competitive everyone is capable of being naturally. Maybe when i look at !praise, !props and #did-a-things. I don’t get activated by seeing others succeed. By succeed i mean the labor it takes to start and follow through even if it means asking for support.

My current stance is that if people were anonymous folx wouldn’t have a choice but to rate the work and the anonymity of it all will make people more reflexive in thier emoting. Seeing a person introduces bias to the labor. This points driving home in my mind as I’m typing it out.

I’ve heard people say over and over !props is just a popularity contest. That sentence makes my heart shudder. Such hurts one must have in them to have sour feelings stir in a !props channel or a !praise channel. I understand a great deal of what festers for people in my community around the #did-a-thing channel and the mental Olympics folx go through having been abused for a lifetime by ableism and processes that support capitalism. I do dream of the architecture being more intentional than it has been and am appreciating the anonymity being presented / discussed here.


are !props and #did-a-thing reward mechanisms from sourcecred?


One point @Griff brought up in a call which I think is important is that anonimizing the praise to some extents kills the “onboarding” dimension of praise, as in: it helps to get a feeling where stuff is happening, and who is involved. This can be specially useful for newer or less involved members to get an overview, and could even be a good way to incentivize joining the quant pool: “Hey, are you new and don’t know where to start? Join a quant, learn about everything that is happening in the TEC and GET PAID for it!”

On the other hand there exist specific onboarding processes, and it’s arguable if praise quants should be involved in that at all…


Yes they’re the cultural pieces I speak to when I long for some more intentional design. I had not heard anything about anyone changing practices with a new instance. I was under the impression sourcecred would be setup the same for this community. I’m curious to know what the differences will be.

I hear that, however there was some lengthy discussion about how explicitly identifying praisors and praisees increases the subjectivity of praise, however not having enough context, as in being able to distinguish one praisee from another, makes it very difficult to quantify. This is especially true in the case of praisees receiving multiple praises for the same thing.

In this struggle between objectivity vs. context we decided this method as the happy medium.

1 Like

I think even if praise becomes anonymous for the quantification it can still be useful for onboarding. People will have an idea of what is happening and what types of contributions are valued in the community. They will start to put the puzzle together once they become more active and have sweet aha! moments finding out who did what in everyday interactions :slight_smile:

1 Like

Here is a rough overview of the Roadmap to First Quant from the Rewards System-

Roadmap To First Quant

  • Agree on the goals of the praise system.
  • Agree on system design within rewards system team and get technical validation
  • Present to community for feedback on system (no params/weights proposed)
  • Spec front-end and back-end requirements
  • Design UI for quantifying praise and reading data
  • Begin development starting with the back-end <---- WE ARE HERE
  • Choose who will be on the Reward Board
    • Nominations? Maximum 5 seats
  • Revisit reward committee proposal and propose changes.
  • Reward Board chooses initial rewards system first set of parameters
    • how many tokens to distribute per cycle? Fixed amount or variable? Do we have caps on individual contributors?
    • Distribution percentages for 3 buckets: Reward Board, Quantifiers, Contributors
    • Distribution Ratio between SourceCred and Praise
    • Weight configurations for SourceCred and praise
    • Use praise receiver pseudonyms during quantification: on/off
    • Max quantifiers per praise receiver: number
    • Max praise receivers per quantifier: number
  • Rewards System Team runs tests on configurations, revise and adjust w/ rewards committee, log simulation results
  • Forum post for advice process on the settings chosen by the Reward Board, adjust proposals based on community feedback.
  • Ratify the Reward System Initial Parameters via Snapshot Vote
  • Make initial funding request from the TEC Treasury/Common Pool with the value denominated in wxDAI, receive TEC or convert it to TEC after receipt in wxDAI.
  • First quant!

Does this Rewards System Design look good?

  • Looks good! BUIDL IT
  • No, I have unresolved concerns in my comments
  • Abstain

0 voters

We’ll make this one of the configurable parameters managed by the Rewards DAO Committee.

Use praise receiver pseudonyms during quantification: on/off

Two other parameters have been identified so far:

Max quantifiers per praise receiver: number

Determines how many quantifiers should do “the same job” of quantifying praise for one person. More quantifiers per praise receiver means increased workload for quantifiers but less risk of personal bias.

Max praise receivers per quantifier: number

Determines the amount of work each quantifier has to do. If above parameter was set to 10, that reads as: One individual quantifier should not have to quantify praise for more than 10 praise receivers.

The two parameters are used in combination to determine the minimum size of the quantifier pool needed. When assigning/randomising quantifiers for a quant period the system will warn if quantifier pool is too small. Option 1 is then to recruit more quantifiers and then assign again. Option 2 is modifying the parameters, increasing quantifier workload or increasing the risk of personal bias but requiring a smaller pool size.


I incorporated these parameters into the appropriate sub-section of the roadmap

Rules for praise and quantification

1 Like

Will there be a system to make comparisons? How do we compare a Dev contribution to a Comms contribution, for example?

Keen to see this! As you might guess from my previous comment.

here’s the forum post to learn more - Rules of Praise and Quantification

1 Like

in the praise system there is no distinction between the type of contributor - a dev contributor is graded on the same metrics as comms - however sourcecred will be able to weigh objective actions (ie. publishing on the forum, retweets, making commits in github…) so we can measure those contributions proportionally based on what we value

1 Like