Command-Line Tool Totaling Contributor Rewards for UBQ Airdrop

[0x4007]

Overview

We are looking to develop a command-line tool that automates the tallying of contributions across all Ubiquity repositories for the last year. This tool will play a crucial role in recognizing and rewarding our contributors' efforts through UBQ token payouts.

Objectives

Tally Contributions

The tool should accurately parse through all the "permits" (or payments for recognized contributions) generated across our repositories to identify and sum up each contributor's total contributions in terms of dollars earned.

UBQ Token Calculation

Based on the dollar value of each contributor's total contributions, calculate the equivalent amount in UBQ tokens, with the conversion rate being 1 UBQ per dollar earned.

Output Format

The results should be compiled into a comprehensive CSV file for each repository, detailing the contributors' names, total dollar earnings, and corresponding UBQ tokens. This CSV file will serve as the basis for UBQ token payouts.

Automation and Execution

This script should be designed for easy execution at specific times, particularly when enabling UBQ token payouts to ensure a seamless distribution process.

Requirements

• Use TypeScript for development to ensure type safety and maintainability.
• Utilize the @octokit/rest library for GitHub API interactions to fetch permits across repositories.
• Ensure the tool is executable through tsx to facilitate integration into our existing workflow.
• Include a testing mechanism that prints test results, which will be a critical part of the pull request QA process.

Final Deliverables

• A fully functional command-line tool meeting the above specifications.
• Documentation on how to set up, use, and contribute to the tool.
• Test cases and results demonstrating the tool's effectiveness and accuracy.
• This tool is integral to our efforts to automate and streamline our reward system for contributors. It will not only enhance our operational efficiency but also ensure transparency and fairness in UBQ token distribution.

We look forward to seeing innovative solutions and contributions from the community to bring this project to fruition.

[CrustalRundrops]

Include a testing mechanism that prints test results, which will be a critical part of the pull request QA process.

Can someone elaborate more on this

[Keyrxng]

/start

Been a minute, hope it's cool to jump in wherever. Has the refactor been completed?

[ubiquibot[bot]]

Deadline	Fri, Feb 16, 8:12 PM UTC
Registered Wallet	0xAe5D1F192013db889b1e2115A370aB133f359765

Tips:

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address.
• Be sure to open a draft pull request as soon as possible to communicate updates on your progress.
• Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the task.

[0x4007]

Include a testing mechanism that prints test results, which will be a critical part of the pull request QA process.

Can someone elaborate more on this

An easy way is to write a GitHub action so we can see that it works in the pull request CI.

[Keyrxng]

Just seen your comment @pavlovcik, haven't built it with that in mind but should be easily repurposed for a GH action. Can you create a new repo for it and I'll open a PR

• https://github.com/Keyrxng/ubq-airdrop-cli

• https://github.com/Keyrxng/ubq-airdrop-cli/blob/master/all_repos_all_payments.csv

using my cex deposits, my tally is accurate for me after adding in the two no-assignee payments of 300 and 12.50 im at about 1556 ish

cases which I've seen:

• New assignee on an issue that has already been paid out see: https://github.com/Ubiquity/research/issues/40 200 paid to hodl but pav is now the assigned so it's been assigned to pav in this particular case

• Payments that have been redacted and added as a debt on their next payment see: https://github.com/Ubiquity/business-development/issues/38 300 paid to hodl but 300 debt added

• deleted GH accounts see: AnakinSkywalker who is now Ghost

Will need to think about how to handle these cases and try to make a more robust way to handle and more importantly verify, and that's what I'm stuck with now how to improve the validity of the findings. Any suggestions?

[0x4007]

Use the ts-template repo GitHub actions for inspiration on how to execute typescript files directly.

Just parse the permits. Use the addresses in place of identities. We don't necessarily need to associate the GitHub user handle to the address in order for an airdrop to work. It's just nice to have.

Every permit for any contribution counts. They can certainly earn rewards without ever being the assignee via comment incentives.

[Keyrxng]

I've been able to identify creator/assignee/conversation rewards from after they were introduced (see here), I went with comment parsing as it seemed more robust in that wallet changes wouldn't affect a hunter's tally.

Only been gone a minute but remind me, are all of the permits stored in the DB?

If going with that approach as opposed to comment parsing then how should I handle:

• Payment made then retracted and debt applied, reduce tally by debt amount or forget it?
• Permit produced then invalidated for whatever reason?
• If payments are to a wallet address not currently registered just forget those?

[0x4007]

Keep it extremely simple. Only a subset of permits are stored in the database, so only rely on the address data encoded in the permit. Don't worry about the penalties. Don't worry about invalidations. Just tally the wallet addresses, don't worry about "registration" (i.e. associating a GitHub user name to a wallet address.)

The main challenge here is that the comment/permit encoding schema has changed a few times since we started this system over a year ago. The script needs to handle these changes.

It would be great if you can sum the totals of each wallet address, as that's the final output numbers we care about. However the detailed breakdown is essential for debugging and auditing the script's capabilities.

[Keyrxng]

• https://github.com/Keyrxng/ubq-airdrop-cli/blob/master/all_repos_contributors.csv

The main challenge here is that the comment/permit encoding schema has changed a few times since we started this system over a year ago

I have covered all the text formats of payment comment that I've been able to find, unless their are reviewer reward comments hidden away somewhere which I wouldn't have been exposed to I'm sure I've covered them all.

I have totalled the contributors already but only through comment parsing, what I'll do is build a permit based version and compare the two results I guess.

Only a subset of permits are stored in the database, so only rely on the address data encoded in the permit.

So the trade off then is that if the db is used then it will cut out large chunk of payments whereas if comments are used the accuracy can't be 100% unless they are all manually reviewed

[Keyrxng]

So I've built this as a CLI tool with multiple commands that parses all repos together or singular repos, allows a time be provided to search from, but that's not sounding right now.

An easy way is to write a GitHub action so we can see that it works in the pull request CI.

Misread that the first time round, seeing it in CI is just for QA but it will function as a CLI ran manually

across all Ubiquity repositories for the last year.

Is this a hardcoded date btw if so then when?

[Keyrxng]

• https://github.com/Keyrxng/ubq-airdrop-cli/actions/runs/7860439292

The current CLI setup as a GitHub action. I've hardcoded the repo name for the sake of QA but we'd pull that from the repo that it's running in

Outputting the files seems a bit extra especially if it's going to be run pretty often

[0x4007]

Is this a hardcoded date btw if so then when?

No we should include every contribution that exists.

https://github.com/Keyrxng/ubq-airdrop-cli/actions/runs/7860439292

Looks pretty good I can spot check by cross referencing repositories later.

Can you open a pull request to this repository with all that code? We can discuss your work on the pull request.

[Keyrxng]

@pavlovcik pr open

[ubiquibot[bot]]

+ Evaluating results. Please wait...

[0x4007]

Looks like we are exceeding the 65536 character length for GitHub comments which is why the bot is failing to post the permits here (too much metadata)

• https://github.com/ubiquibot/comment-incentives/issues/19

Standby for a fix!

[0x4007]

I'm going to try and salvage the permit link from the logs

[ubiquibot[bot]]

+ Evaluating results. Please wait...

[0x4007]

[ 228.2 WXDAI ]

@pavlovcik

Contributions Overview

View	Contribution	Count	Reward
Issue	Specification	1	80.8
Issue	Comment	6	64
Review	Comment	7	83.4

Conversation Incentives

Comment	Formatting	Relevance	Reward
## Overview We are looking to develop a command-line tool tha...	80.8 h2: count: 4 score: "4" words: 5 h3: count: 4 score: "4" words: 10 li: count: 8 score: "8" words: 127 code: count: 1 score: "1" words: 1	1	80.8
> > Include a testing mechanism that prints test results, which ...	4.2	0.59	4.2
Use the ts-template repo GitHub actions for inspiration on how t...	14.6	0.69	14.6
Keep it extremely simple. Only a subset of permits are stored in...	25.4	0.73	25.4
> Is this a hardcoded date btw if so then when? No we should ...	8.4	0.77	8.4
Looks like we are exceeding the 65536 character length for GitHu...	8.8 li: count: 1 score: "1" words: 8	0.7	8.8
I'm going to try and salvage the permit link from the logs...	2.6	0.77	2.6
I think that parsing the encoded permits from within the GitHub ...	8	0.695	8
I appreciate you taking the time to check your work. You can mar...	4.4	0.77	4.4
Hey last thing but I'm hoping to see a workflow run can you add ...	8.8	0.79	8.8
This doesn't sound right because I've been using `tsx` for proba...	30.6 code: count: 2 score: "4" words: 2	0.755	30.6
I have to see the commit lint error you're talking about because...	22.6	0.735	22.6
Can give the full review post merge given the delay and initial ...	2.6	0.73	2.6
[ 486.7 WXDAI ] @Keyrxng Contributions Overview View Contribution Count Reward Issue Task 1.00 400 Issue Comment 6 0 Review Comment 9 86.7 Conversation Incentives Comment Formatting Relevance Reward Just seen your comment @pavlovcik, haven't built it with that in... - li: count: 5 score: "0" words: 0 0.65 - I've been able to identify creator/assignee/conversation rewards... - a: count: 1 score: "0" words: 2 li: count: 3 score: "0" words: 35 0.705 - ![image](https://github.com/ubiquity/.github/assets/106303466/93... - li: count: 1 score: "0" words: 11 0.78 - So I've built this as a CLI tool with multiple commands that par... - 0.74 - - https://github.com/Keyrxng/ubq-airdrop-cli/actions/runs/786043... - li: count: 1 score: "0" words: 10 0.685 - @pavlovcik pr open ... - 0.76 - After you give this a look over let me know if this is the way f... 7.7 0.65 7.7 validating the non_payment repos I found one newer style comment... 2.8 0.665 2.8 - Now pulling all permits: 448 tracked - Payments assigned to u... 33.7 a: count: 1 score: "1" words: 1 li: count: 4 score: "4" words: 0 code: count: 2 score: "2" words: 5 0.72 33.7 I don't think I can take this any further without input on it as... 3.9 0.76 3.9 Is tsx a requirement if it's running fine with tsc? I can run th... 8.8 a: count: 1 score: "1" words: 3 0.725 8.8 I'll see what I can do with it then pav and I'll make the final ... 3.3 0.805 3.3 Keyrxng commented 4 months ago I'm going to try and salvage the permit link from the logs I beat you to it this morning when I realised it was sitting in the logs (had I not been skint rn I'd have left it) Was gonna jump in and try resolve the issue myself until I realised it's AI heavy and I had an API bill to pay 🤣 however with that said, I'll likely attempt it later Keyrxng commented 4 months ago 86 bucks for conversation that's mad 0x4007 commented 4 months ago 86 bucks for conversation that's mad In the future we will augment the bot's capabilities to determine if the subject is accurate. For example: on the issues page, the conversation should only be around refining the scope of work with clarifications on the scope, research to improve the approach to solving the problem, etc. In the pull request review, the conversation should focus on improving the code quality. Although I think in a more advanced stage, we would very likely remove the assignee rewards for commenting on the pull request review. Or maybe we can just add a configuration option to enable/disable this based on the repository. However I think the assignee should be eligible for rewards to contribute to researching the original issue specification before they take on the task. Lastly I do full expect to increase the rewards by 2-4x as we move the core team off of salaries. In this way, the bot should be finely tuned to incentivize the precise behavior we seek, and developers should make good living wages if they pursue these incentives. Keyrxng commented 4 months ago I agree hashing out the spec should surely count but pr comments nah, you've accepted the terms as soon as the /start command is ran if you ask me 😂 esp considering those PRs that extend months and amount to double digit review attempts, too easily gamed. Well if I never end up making the cut before then I'll still be glad to be around when that does happen. My annual hiatus is over so I'll be pushing often again wherever I can be of value © Githubissues. Githubissues is a development platform for aggregating issues.

[Keyrxng]

I'm going to try and salvage the permit link from the logs

I beat you to it this morning when I realised it was sitting in the logs (had I not been skint rn I'd have left it)

Was gonna jump in and try resolve the issue myself until I realised it's AI heavy and I had an API bill to pay 🤣 however with that said, I'll likely attempt it later

[Keyrxng]

86 bucks for conversation that's mad

[0x4007]

86 bucks for conversation that's mad

In the future we will augment the bot's capabilities to determine if the subject is accurate.

For example:

• on the issues page, the conversation should only be around refining the scope of work with clarifications on the scope, research to improve the approach to solving the problem, etc.
• In the pull request review, the conversation should focus on improving the code quality.

Although I think in a more advanced stage, we would very likely remove the assignee rewards for commenting on the pull request review. Or maybe we can just add a configuration option to enable/disable this based on the repository. However I think the assignee should be eligible for rewards to contribute to researching the original issue specification before they take on the task.

Lastly I do full expect to increase the rewards by 2-4x as we move the core team off of salaries. In this way, the bot should be finely tuned to incentivize the precise behavior we seek, and developers should make good living wages if they pursue these incentives.

[Keyrxng]

I agree hashing out the spec should surely count but pr comments nah, you've accepted the terms as soon as the /start command is ran if you ask me 😂 esp considering those PRs that extend months and amount to double digit review attempts, too easily gamed.

Well if I never end up making the cut before then I'll still be glad to be around when that does happen. My annual hiatus is over so I'll be pushing often again wherever I can be of value