Web: Gitcoin KPI Additions

[vs77bb]

Gitcoin KPI Addition Suggestions

Using Q2 OKR's as a source for what we need to track better.

Work For Gitcoin Developers

• Lifetime 'Work Done', ideally static in USD (Blocker: #491)
• Current work 'Open' on the platform; ideally static in USD (Blocker: #491)
• Current active work in the platform ('Work Started' + 'Work Submitted') ideally static in USD (Blocker: #491)

Success With Repo Owners

• Current number of repo's with issues in progress (either 'Open', 'Work Started', or 'Work Submitted')
• Current number of repo's with at least 3 issues in progress (either 'Open', 'Work Started', or 'Work Submitted')
• Current number of repo's who have successfully bountied at least 3 issues total (either 'Open', 'Work Started', 'Work Submitted', or 'Work Done')
• Median Turnaround Time: Track how long the average issue takes to get from posted and 'Open' to 'Work Done'
• Percentage of bounties that make it from 'Open' to 'Work Done'
• % of bounties completed within funder timeline

Anything Else?

[owocki]

Current work 'Open' on the platform
Current active work in the platform ('Work Started' + 'Work Submitted')

measured in dollar vlaue, eth value, num issues?

[vs77bb]

@owocki Updated to say 'ideally static in USD (Blocker: #491)'...

I think we should just go with the rolling / non-static USD value for now if #491 might take a while... it's a weird nuance where the fluctuations in ETH affect the amount people stake given their preconceived notions about it's inherent value... but the metric is too important to not track in some way 🤔

[mkosowsk]

@vs77bb think this makes #491 come into the forefront even moreso... Would recommend taking some cycles to get #491 to "Definition of Ready" for community to take a swing at, think it would be a big value add 👍

[mbeacom]

@vs77bb Honestly, #491 should be fairly simple to track current bounty value moving forward. I'm not entirely sure how @owocki wants us to approach it, but storing the current value of a bounty when it's created shouldn't be a big deal. We need to figure out how/what we want to display in the dashboard per entry and on the bounty details page. Once we come up with that, the task shouldn't take long at all. We should be able to populate the original ethereum price from our historical ConversionRate data based on timestamp during the django model migration phase.

[owocki]

We should be able to populate the original ethereum price from our historical ConversionRate data based on timestamp during the django model migration phase.

unfortunately many ConservationRate entries have been purged from the db by 'cleanup_db_space' script

[mkosowsk]

Currently using CryptoCompare for another project and think it may work for our purposes here? I am using it for real-time data but looks like they have historical options.

I would prefer Python, but here's an NPM module that @owocki seems to prefer: https://www.npmjs.com/package/cryptocompare

[mbeacom]

If we're handling historical data during migrations, I think it maybe more sensible for us to use a python module like https://github.com/lagerfeuer/cryptocompare or the api directly https://www.cryptocompare.com/api/

[vs77bb]

@mbeacom @owocki @PixelantDesign To follow up, here are the next steps as I see.

• Bounty #491 suggesting https://github.com/lagerfeuer/cryptocompare or https://www.cryptocompare.com/api/ as data sources
• Begin building out the views in admin for all suggested views where #491 (i.e. $ price) is not a blocker

I think we should raise priority here, as it affects how we track against Q2 OKRs. Thoughts?

[owocki]

we need to decide if were gonna use looker or metabase for this (edit: internal admin might be fine)

[owocki]

note that #491 is in progress here => https://github.com/gitcoinco/web/issues/693#issuecomment-378514081

@cryptomental is on the case

[vs77bb]

@cryptomental Appreciate the help here. This is huge for us tracking against our OKR's

[cryptomental]

@owocki , @vs77bb I added CryptoCompare support. get_prices command iterates through bounties, if ConversionRate is not available for web3_created bounty timestamp it pulls data from CryptoCompare . See commit 307ef0e

[owocki]

@vs77bb i just created a new ticket with a different approach to this at https://github.com/gitcoinco/web/issues/1020 -- might be worth checking out and comparing / contrasting approaches. we could do both/either.

[frankchen07]

@owocki & @vs77bb Late to the KPI discussion, but my suggestions for OKR improvement run along the lines of understanding user engagement.

I like active work, work open, and work done (denominated in USD), but it tells a different value story than something like a "work done per active Gitcoin developer" (basically breaking it down to a user-level). If I'm thinking from a user perspective, and I visit the results page, seeing USD denominated work amounts tells me that the platform is healthy, but as a developer, I'd be curious to get an immediate read on how many issues, how much time, and how much money I'm able to earn just by looking at a user-level rate.

It'll be up to us to define what active means (front end tracking (impressions and clicks) of the issue explorer, having a certain amount of issues open per time period or having submitted work per time period). Taking a look at the distribution of our users will give a good ballpark as to where that sits.

[frankchen07]

Lower priority for the gitcoin/results page:

Joe dominance index: This is a good opportunity to share who the the other funders are via a color banded graph over time. A graph like this: https://blog.unchained-capital.com/bitcoin-data-science-pt-1-hodl-waves-7f3501d53f63

Hourly rate of bounties: Love the viz, but circle area, according to Tufte :), is pretty tough to estimate. I see a comparison of hourly rate on age of bounty, with the area representing how many bounties there are. It gets me curious enough to see how pricing is done, so if that's the main goal, then success!

[kuhnchris]

@frankchen07 @vs77bb did this get superseeded or is this still relevant?

[frankchen07]

@kuhnchris - I'd say this is lower priority right now

[kuhnchris]

OK, i'm throwing it into the backlog priority for now then. Thanks. :-)