Contributor leaderboard

[Keyrxng]

It has been discussed across various issues, PRs and discussion threads and with recruitment on-going it might be a good thing for newbies to visually see what other contributors have earned, even 1x'ers like me 🤣

---

1. List contributors by earnings (only available marker right now)
2. Display contributor's username in place of their EOA
3. display a preview modal with additional metadata about the contributor
4. Later the XP system, Karma, etc... can all be built into the metadata modal.
5. Fetch the leaderboard data from an up to date source (new task for a GH action to run every 24hrs and update the source?)
6. Cache what data we can

[rndquu]

@Keyrxng It would be great to first put a time estimate and got a confirmation that the issue is worth implementing it. Otherwise you risk spending time on unnecessary stuff.

What time estimate should we put here?

[Keyrxng]

an hour or two is fine

I'll be sure to estimate future issues, I thought that was above my pay grade so to speak 😂

[ubiquibot]

@Keyrxng the deadline is at 2024-05-15T10:25:11.193Z

[rndquu]

an hour or two is fine

I'll be sure to estimate future issues, I thought that was above my pay grade so to speak 😂

Just make sure to confirm issue description and time estimate with somebody from the ubiquity org

[zugdev]

Number of completed tasks is also a good criteria to have!

[ubiquity-os]

@Keyrxng the deadline is at Tue, Oct 8, 6:06 AM UTC

[rndquu]

We need a simpler way to fetch leaderboard statistics. Perhaps we need to update https://github.com/ubiquity/devpool-directory/blob/__STORAGE__/devpool-statistics.json to collect rewards per user and simply use that file as a DB for leaderboard.ubq.fi.

[Keyrxng]

We need a simpler way to fetch leaderboard statistics. Perhaps we need to update https://github.com/ubiquity/devpool-directory/blob/__STORAGE__/devpool-statistics.json to collect rewards per user and simply use that file as a DB for leaderboard.ubq.fi.

Far simpler going forward if that's implemented yeah.

Building an accounting of the startup's payouts going back as far as I did would be much tougher imo and comes with a zoo of it's own problems.

I've authored code to scrape everything from GitHub but it's verifying the data that's the issue which is where the complicated on-chain stuff came into it. As shown by my QA the GH scraped and the on-chain verified is drastically different due to things like multiple permits per task etc.

---

1. Only collect earnings going forward (terrible, prev contributions should stand for something)
2. Use just the GitHub scraped data without attempting to validate on-chain (better but still bad)
3. Do 2 and later have someone better than me implement on-chain validation.

---

Because this was seeding the leaderboard AND the future airdrop as well as would be the only accurate accounting the startup has on payouts I felt the results had to be checked and rechecked and made to be as close to truly accurate as possible.