-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Command-Line Tool Totaling Contributor Rewards for UBQ Airdrop #95
Comments
Can someone elaborate more on this |
Tips:
|
An easy way is to write a GitHub action so we can see that it works in the pull request CI. |
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 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:
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? |
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. |
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:
|
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. |
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.
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 |
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.
Misread that the first time round, seeing it in CI is just for QA but it will function as a CLI ran manually
Is this a hardcoded date btw if so then when? |
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 |
No we should include every contribution that exists.
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. |
@pavlovcik pr open |
+ Evaluating results. Please wait... |
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) Standby for a fix! |
I'm going to try and salvage the permit link from the logs |
+ Evaluating results. Please wait... |
|
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 |
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:
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. |
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 |
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
tsx
to facilitate integration into our existing workflow.Final Deliverables
We look forward to seeing innovative solutions and contributions from the community to bring this project to fruition.
The text was updated successfully, but these errors were encountered: