Let's Discuss Community Rewards Type/Value Adjustments for 2023!

[AlgoRhythMatic]

Happy New Year!

In the interest of keeping ASA Stats engagement and participation as strong as possible in the new year, I'd like for our community to review our current community rewards types and values, and make adjustments ahead of our first 2023 cycle close next Friday, January 13th.

What I'd like to accomplish with this discussion

1. Review contribution types and definitions, and add/remove entries based on what we're actively using.
2. Review the levels/values per type to see if they make sense.
3. Simplify and adjust values to not remove need for a multiplier (at least until we encounter notable price fluctuations in 2023).

Our current rewards contribution types and values

A) here are our current contribution type definitions adapted slightly from our ASA Stats Contribution Rewards spreadsheet:

Contribution Type	Definition	Level 1	Level 2	Level 3
[AT] Admin Task	A task to produce some work that facilitates community administration across official channels. Examples: creation of contributor lists, reference checking, setup of Discord bots, cross-posting comments, or any task where the prescribed output leaves little room for interpretation.	The task takes up to 1 hour to complete	The task takes 1 to 2 hours to complete	The task takes 4 or more hours to complete
[B] Bug Report	Report of a untracked defect or unexpected behavior on asastats.com.	The bug report provides context (e.g. OS version, browser) and helpful steps to reproduce the faulty behavior.	Contributor engages with ASA Stats to provide more information and assists in testing during resolution, acknowledges when fix is satisfactory.	Contributor provides deep insights that directly impacts resolution (e.g. browser side code analysis)
[CT] Content Task	A task to produce written content that helps ASA Stats achieve its stated goals. Examples: an announcement in an official channel, copywriting for the asastas.com website, an email to form a partnership, or a submission to a partner site.	The task takes up to 1 hour to complete.	The task takes 1 to 2 hours to complete.	The task takes 4 or more hours to complete.
[D] Discussion	A sustained public channel discussion on a relevant ASA Stats topic, where one or more contributors make insightful comments keeping the community engaged	The contribution contains factually correct information, balanced opinions, and provides a substantive amount of the discussion with several other members.	N/A	N/A
[F] Feature Request	A request for a new feature or functionality improvement for ASA Stats.	The request is specific, original, and generates sufficient support from the community (i.e. reactions and replies).	The request is well thought-out, and includes a suggested path to implementation.	The request is backed with a significant volume of research (UI mockups, technical analysis, etc.)
[MT] Marketing Task	A marketing or PR task that helps to improve ASA Stats' visibility or reputation.	The task takes up to 1 hour to complete.	The task takes 1 to 2 hours to complete	The task takes 4 or more hours to complete
[R] Research	Research that provides new and relevant information related to ASA Stats' operations or the Algorand ecosystem. Useful research should contain original sources, and clearly explain how/why it addresses an official ASA Stats announcement or request (re: partnership, data source integration, etc.)	The research takes up to 1 hour to complete, and is specific, original, and generates sufficient support from the community (i.e. reactions and replies).	The research takes 1 to 2 hours to complete, and contains a thorough well-thought process and a path to implementation.	The research takes 4 or more hours to complete, and is backed with a significant volume of research (research, draft proposal, technical analysis, etc.)

B) the following are our current rewards values model in damo (where 1 damo = 1M ASASTATS), per type/level from the ASA Stats Contribution Rewards spreadsheet:

Contribution Type	Level 1	Level 2	Level 3
[AT] Admin Task	0.012	0.019	0.044
[B] Bug Report	0.011	0.017	0.029
[CT] Content Task	0.010	0.020	0.040
[D] Discussion	0.010	#N/A	#N/A
[F] Feature Request	0.010	0.019	0.029
[MT] Marketing Task	0.011	0.023	0.036
[R] Research	0.010	0.022	0.031
[S] Suggestion	0.010	0.021	0.030

Current process in a nutshell

For the past 6 months or so, the original values seen above have been multiplied by a coefficient (based loosely on ASASTATS price fluctuations), which currently set to 3x. Rewards entries are entered into an Ongoing Contributions tab in the spreadsheet, which ultimately tallies rewards per-member that are processed and sent to the community.

To avoid making this initial posting longer than it already is, I'll start off the conversation w/ my own thoughts as reply threads!

[AlgoRhythMatic]

Thought 1 - type refinement

The main contribution types we currently reward are:

• Bug Report
• Feature Request
• Content Task (ambiguous)
• Admin Task (ambiguous)

I think we should consider adding types/levels that directly consider the following:

• Tweets (composing and sending)
• Meeting attendance
• Meeting notes

Please reply with additional types that should be rewarded, as well as thoughts/comments regarding potential to adjust or remove some types.

[kerrilija]

I assume 1:1. 1x GitHub issue bug report = 2x Discord bug report?

[ipaleka]

Do you think [IC] should be valued equivalently alongside of [B] as 1:1, or should [IC] be valued less?

Whatever you find suitable tbh. We need to motivate community members to collect requests and bug reports from community channels. For me personally, it would be perfect if I can visit GitHub knowing all the issues are there.

[AlgoRhythMatic]

I was thinking more along the case where a person in Discord has a [B2] or [B3]. Should the person to transcribe the request also get the 2nd or 3rd level value on their [IC] for transcribing (if this might have take a lot less effort)?

Another way to consider it - should [IC] damo rewards values match [B] and [F] rewards values at each level?

[ipaleka]

I was thinking more along the case where a person in Discord has a [B2] or [B3]. Should the person to transcribe the request also get the 2nd or 3rd level value on their [IC] for transcribing (if this might have take a lot less effort)?

I guess that would be counterproductive, someone who spent time and effort getting B3 shouldn't affect a dull and easy repeating process like issue creation is. I'd rather that we set the starting IC value just like B or F value - I'm talking about the form, not that it has to be valued the same - and then for issue creation that required more effort we simply set that particular effort as IC2 or IC3...

Another way to consider it - should [IC] damo rewards values match [B] and [F] rewards values at each level?

I guess we can start with the same value for IC as for F and B (or lower of two if those starting B and F would differ in the future based on this discussion), and that we adjust with time if needed.

[AlgoRhythMatic]

I guess that would be counterproductive, someone who spent time and effort getting B3 shouldn't affect a dull and easy repeating process like issue creation is. I'd rather that we set the starting IC value just like B or F value - I'm talking about the form, not that it has to be valued the same - and then for issue creation that required more effort we simply set that particular effort as IC2 or IC3...

So then in a majority of cases where it is cut/paste, a person transcribing a bug should get an [IC1] of .03 damo (for a straight forward [B2] or [F2]?

[AlgoRhythMatic]

Thought 2 - value refinement

I think our reward values baseline should now "bake in" our 3x multiplier and become a bit flatter. The following considers the most common types from "type refinement" above:

Contribution Type	Level 1	Level 2	Level 3
[AT] Admin Task	0.035	0.070	0.150
[B] Bug Report	0.030	0.060	0.135
[CT] Content Task	0.030	0.060	0.135
[F] Feature Request	0.030	0.060	0.135

Questions:

1. Should Bug Report, Content Task, and Feature Request all be valued the same? Why or why not??
2. Are these values good/bad/otherwise given the time and efforts of the community + current value of ASASTATS?

[kerrilija]

Contributions should be evaluated based on three aspects:

1. Required skill - A task that can only be done by 5 people should be rewarded more that a task that can be done by 50,000 people.

2. Required time - A task that requires 3 hours of work should be rewarded more than a task that requires 20 minutes.

3. Importance/Impact/Priority - Tasks have different "values". Visual bugs, typos or similar are less harmful than an incorrect representation of a token value, for instance.

I think Feature requests & bug reports should be equally rewarded. As much as we want to collect the maximum amount of data from the blockchain, we also want to represent that data accurately (bugless).

Content rewarding

We need Twitter so that people know ASA Stats is active and evolving constantly. Blog posts are also very important, so people can have a deeper insight about everything. Tweets usually take up to 30 mins, from crafting to posting, while blog composing takes hours, even days with revising etc. Blog posts can truly change people's opinion/stance about the project since they potentially start to appreciate its value more. They are also more important IMO and fewer people will ever start writing one.

Community rewards processing

IMO this Admin task should be at least 0.15 damo. It's of high importance, and evaluated at less than 2 tweets at the moment.

[kerrilija]

I was thinking maybe we adjust and reduce "level" designations a bit in terms of time swags, so that a L1 is 1-30 min, L2 is 30-60 min, and L3 is 60-120+ min (as a starting point).

I totally agree with this, makes more sense than current "levels", it is more precise. Up until now we were rewarding .06 damo per tweet, if we reduce it to .03 damo, community members will be even less motivated to participate. But the market sentiment seems to be getting better, so we can go with your proposal, if you ask me. Also, [TWR] should be separated from the more general [CT]. (see below)

I think we can use the [CT] (Content Task) designation for blog posts, and also measure per-hours of effort. Since the baseline levels are longer for blogs, maybe we stick with 1 = <1hr, 2 = 1-2hrs, and 3 = >3?

We can stick with [CT]. Although, I suggest a significant raise of rewards in this section:
[CT1] = .1 damo
[CT2] = .2 damo
[CT3] = .3 damo

For creating the first 3 blog posts @ipaleka suggested 2.0 damo (0.67 damo per post) in a Discord message, which may be a bit too much. As a reference, I've looked up how much is writing actually paid online:

On Upwork, the rates for top content writers can range from as low as $15 dollars an hour to as high as $80, though most fall in the $30-50 range.

0.1 damo = 11.9$, so that would mean that a writer at ASA Stats makes 3$ less an hour than the worst paid "top content writer" on Upwork.

[AlgoRhythMatic]

I totally agree with this, makes more sense than current "levels", it is more precise.

I've updated the ASA Stats Contribution Rewards spreadsheet with:

• reduced levels (1: 1-30 mins, 2: 30-60 mins, 3: 60-120+ mins) for Bug Report, Feature Request
• added Twitter Composition/Posting, and Issue Creation, which also have same time swags as [B] and [F].

Here is an attempt to gather the new values based on what we've discussed here:

Contribution Type	Level 1	Level 2	Level 3
[B] Bug Report	0.03	0.06	0.135
[F] Feature Request	0.03	0.06	0.135
[IC] Issue Creation	0.03	0.06	0.135
[TWR] Twitter Post	0.03	0.06	0.135
[CT] Content Task	0.1	0.2	0.3
[AT] Admin Task	0.035	0.07	0.15

Up until now we were rewarding .06 damo per tweet, if we reduce it to .03 damo, community members will be even less motivated to participate. But the market sentiment seems to be getting better, so we can go with your proposal, if you ask me.

So, is it fair to say most of your Twitter efforts (composing, editing, reviewing, posting) fall into the 30-60 minute of effort? If so, this would classify as [TWR2] and would be .06 damo per above. In cases were it took >60 minutes (let say 90 due to coming back and multiple edits + posting), then it would now be .135 damo. But say it is super simple, and just a quick suggestion and post...then it would be .03. I'm just the moderator, so you can certainly adjust higher if you or @ipaleka think we should.

We can stick with [CT]. Although, I suggest a significant raise of rewards in this section:

I added your suggested values to chart above, and kept current time swags of 1, 2 and 3+ hrs for CT. As you noted about @ipaleka suggested values of .67 per post, let's see how it falls in line with what we have in terms of time spent per above. It may be that we need to adjust up for original content per your next thought.

0.1 damo = 11.9$, so that would mean that a writer at ASA Stats makes 3$ less an hour than the worst paid "top content writer" on Upwork.

Yes, it is true the "royal we" aren't paying top dollar per current global market rates, but I personally think that we sort of have to take it in stride that ASA Stats does not have a payroll per-se (in the same way that some organization with large investment would), and should focus on staying sustainable for the long run. I know this may not be the popular opinion, and am certainly open to adjusting however all see fit.

What do you think?

[kerrilija]

So, is it fair to say most of your Twitter efforts (composing, editing, reviewing, posting) fall into the 30-60 minute of effort? If so, this would classify as [TWR2] and would be .06 damo per above. In cases were it took >60 minutes (let say 90 due to coming back and multiple edits + posting), then it would now be .135 damo. But say it is super simple, and just a quick suggestion and post...then it would be .03. I'm just the moderator, so you can certainly adjust higher if you or @ipaleka think we should.

Agree!

Yes, it is true the "royal we" aren't paying top dollar per current global market rates, but I personally think that we sort of have to take it in stride that ASA Stats does not have a payroll per-se (in the same way that some organization with large investment would), and should focus on staying sustainable for the long run. I know this may not be the popular opinion, and am certainly open to adjusting however all see fit.

I wasn't posting this Upwork reference to say the rewards are to small, rather just to make a comparison. The Algo DeFi is still at the beginning, there is not as much audience for those posts comparing with the "Upwork made" ones, for sure. Therefore, I think we made a good job defining the new levels.

Thank you for all of your efforts!

[ipaleka]

I'm okay with whichever decision about the quantity of the rewards. No matter how many contributors are involved, we should be satisfied if a job is done.

Also, I'd be glad if we could create a dedicated proxy pool from where you (@AlgoRhythMatic , @kerrilija , @dragmz , ...) would be able to allocate funds for rewards, incentive programs, giveaways, etc. @dragmz can update his home-made scripts for allocation so they accept multisigs from two prominent members or so. We simply have to start moving toward a true community project IMO...

[AlgoRhythMatic]

I'm in support of whatever is easiest to maintain, is the most transparent, and has fair checks and balances to avoid any errors or improprieties (real or perceived) :)

[moloch10]

I'm reading all the posts but don't have much to contribute I suppose. I've been more than satisfied with how it's been going and I'm sure that'll continue. Thanks for your work in keeping track of everything.

[kerrilija]

by @ipaleka in Discord

Tho I'm not sure if we need any additional remark... AlgoRhythMatic will see from quote and related user who is original poster... I mean [B+IC] is correct, but I guess even without it we'll be ok...

Are community users supposed to put these tags? Or the person in charge for rewards processing only?

EDIT:
I've been adding [twr] tags in the past. We should define what works best for us. It is maybe easier to "collect" those tags, and not going through 100 Discord messages sometimes. What do you think?

[ipaleka]

by @ipaleka in Discord

Tho I'm not sure if we need any additional remark... AlgoRhythMatic will see from quote and related user who is original poster... I mean [B+IC] is correct, but I guess even without it we'll be ok...

Are community users supposed to put these tags? Or the person in charge for rewards processing only?

That's the job of either the issue creator or the person who closes the issue and adds the "addressed" label to it.

If you as the issue creator contemplate about the reporter and see that they made some additional effort then feel free to mark it as B2 or F3. Maybe we don't need to add IC to the issue title as it is implied that @AlgoRhythMatic will notice that the issue creator differs. If someone in the process recognizes more effort than usual then IC2 (or IC3) can be added...

EDIT: I've been adding [twr] tags in the past. We should define what works best for us. It is maybe easier to "collect" those tags, and not going through 100 Discord messages sometimes. What do you think?

You created two Discord comment today or yesterday where you suggest rewards. That's the correct first step and after while another Discord comment for each tweet should be created starting with [twr] and then the final rewards in it. That way AlgoRhythMatic can put in the search box the following:

in: tweets-composing twr

And simply check for such comments after the previous cycle.

[kerrilija]

We'll see what @AlgoRhythMatic thinks would be the best practice. Then we'll be able to define in what cases community members add those tags.

[ipaleka]

We'll see what @AlgoRhythMatic thinks would be the best practice. Then we'll be able to define in what cases community members add those tags.

Yes, you're completely right, everything about this is done for the Rewards Cycle Ceremony Master so he can get a grasp on the right rewards amounts and related recipients.

[AlgoRhythMatic]

If you as the issue creator contemplate about the reporter and see that they made some additional effort then feel free to mark it as B2 or F3.

I'm happy for anyone to ALWAYS add tags to issues they create - I can ask/agree/disagree as needed, but it is a helpful guideline. Unless I see a ton of back/forth, I tend to think things are simple and classify nearly everything a level 1. So it is to say, if you know that something is an L2 or L3...it is super helpful to mark it as such.

Maybe we don't need to add IC to the issue title as it is implied that @AlgoRhythMatic will notice that the issue creator differs. If someone in the process recognizes more effort than usual then IC2 (or IC3) can be added...

I will try my best to see when a person submitting an issue differs from the person who reported it, but won't hurt to add [IC1] - though I don't want to overcomplicate things, so won't try to hold people to it :)

I've been adding [twr] tags in the past. We should define what works best for us. It is maybe easier to "collect" those tags, and not going through 100 Discord messages sometimes. What do you think?

You created two Discord comment today or yesterday where you suggest rewards. That's the correct first step and after while another Discord comment for each tweet should be created starting with [twr] and then the final rewards in it. That way AlgoRhythMatic can put in the search box the following:

Yes, the [TWR] tag is key to search for from Discord! In cases where it didn't exist, I'd come through and add it so there were 1:1 after a cycle. Now that we have L1 (1-30min), L2 (30-60), and L3 (60-120+) guidelines, I'd say either the person posting can self-identify work they've done...say @kerrilija composes, edits, and posts, just mark a single [TWR2] or [TWR3] - or if an active participant sees another person posting/composing - they can add the tag as part of a suggested reward. The key is just have 1:1 tag:event so I can query for them.

Edit: I will probably also start looking at the "ASA Stats • TweetShift" events in announcements to ensure that I don't miss any tweets handled by community members other than @ipaleka

[AlgoRhythMatic]

So then, if we agree on values added in the 2nd chart here: #405 (reply in thread), then I can go ahead and update the spreadsheet to begin adding current [B], [F], [IC], and [TWR] rewards as a test.

In regards to [CT], I'm hopeful that we can enter some Github issue about each blog post, or otherwise define a process to track how we'll measure time spent in that pursuit.

Otherwise, please let me know if there is more to discuss here!

[ipaleka]

I'm absolutely for the system in which we create an issue for each task that is going to be rewarded. Even for the already finished tasks. An exception to the rule can be creating issues for tweet composing as our dedicated Discord channel and your searching for twr have functioned well so far imo.

[AlgoRhythMatic]

So then I think we have everything covered, until we get to initial blog rewards cases, and can enter a GitHub task that details hours spent or similar for reference.

[AlgoRhythMatic]

Quick note: I’m on vacation after Friday evening(for about a week), traveling, so I’ll be trying to get a head start on this tomorrow, and any final changes on Friday AM my time.

[ipaleka]

I want to suggest something that's out of being based on time spent and/or effort.

It's about completely new providers or completely new smart contracts in their portfolios (the latter is for the cases when for example provider deploys parts of their website previously marked as soon or a similar upgrade). When a new provider hits the Mainnet that implies research and my opinion is that we should reward such a request more than a regular new staking program or a new farm, as that implies rewarding community members' involvement in the ecosystem and its news. IMO we should motivate such presence in the ecosystem.

Implementation of this doesn't need to be a separate reward category, I can just add F2 for such a request (or F3 if the original effort would have been set as F2).

[AlgoRhythMatic]

Sounds reasonable to me!

[ipaleka]

So @kerrilija has started bug fixing and adding features for mobile app(s). #724

@AlgoRhythMatic, I guess it'd be easiest for whoever closes an issue to set both Dx and Bx/Fx for those mobile issues. D1 is implied, but to avoid mistakes we should add it together with B or F mark.

• B or F reward goes to the reporter (the person who created the issue or who is mentioned in the issue quote).
• IC goes to the creator of the GitHub issue.
• new: D reward goes to the person who closed the issue (it is expected that only kerrilija is that person for the very next rewards cycle).

[ipaleka]

We can also increase the coefficient and that way help you become a whale. :)

[AlgoRhythMatic]

100 D working hours (2.5 work weeks) gets you 1% of total ASASTATS supply, to put it in a different perspective :)

I like your optimistic long view!

[AlgoRhythMatic]

D1 is implied, but to avoid mistakes we should add it together with B or F mark.

One more comment to this point: yes, I think it is always helpful to add numbers if they are known. I default to B1/F1, unless there is some clear effort, longer exchanges, or it is noted in the title. In terms of D1/2/3, I'm hopeful that the closer can self-report this part - either in title, or in a comment. As well, mostly for @kerrilija - the way that @ipaleka has counted >3 to date is to use some notation like 2 x D2 or 2 X D3 to get to the correct count. But I will always try and reach out or comment in any case where there is not 100% certainty.

[ipaleka]

This set of just-resolved issues by @kerrilija is a good starting point, while all are still fresh in memory.

Btw, there have also been some administration-development tasks involved by him, setting up the environment for publishing to app stores. We can set it either as an admin task or a developer task, dunno.

[AlgoRhythMatic]

I think Admin Task is probably best for that. The hour requirements are lower for that one too.

[ipaleka]

@AlgoRhythMatic IIRC we haven't discussed this part, but it seems it is intuitive.

So, I guess we should stick to the time-based, left-to-right approach. In this case (F1+IC1+D1), F1 happened first (Maximus), then IC1 (@kerrilija) created the issue, and finally D1 (it is implied that kerrilija does all the mobile development, we'd emphasize other people if not).

[kerrilija]

Isn't this particular F1 in collision with other features that are requested but not developed and added to wiki? Or features(suggestions) that were implemented in history and not rewarded? Lately, F1 was only being given to people requesting pool tracking etc. I might be wrong tho.

[ipaleka]

Every feature request for dependable features from the wiki should get rewarded eventually after the actual implementation. We set the ordinal next to an F for the amount of time, knowledge and resources spent. In this particular case, I thought F1 is ok.

We have tried to reward every feature request that has been implemented and if we miss some that can be corrected. :)