clr_self_service.md

CURRENT STATE

• Finalize Model Design
• Make Data Model Changes
• Custom Migration to preserve data
• Fix Broken Pieces
  • Grants (Creation + Display + Fund)
  • CLR
  • Sybil

Goal

CLR round should be a self-service solution. This would enable admin to

• renew a clr round for an existing grant type (tech/health/..)
• start up a new clr round for a new grant category (like matic)

Ideally we'd want this to be

Expection From Reviewer

• Validate each section and suggest what works and what doesn't
• Evaluate idea as a whole and suggest if it's even worth doing / do we keep it offline

Lifecycle

Setting a CLR for a new Grant Type

• Admin would add a new entry in GrantType
• If the new Grant Type needs to CLR -> the details would be added in the above step as well
• To activate the CLR round -> the admin will have to set the is_active_clr to True
• Admin would add a new entry in GrantCategory which is mapped to the above GrantType

Setting a CLR for an exsisting Grant Type

• Admin would update the relevant entry in GrantType with the CLR round details
• To activate the CLR round -> the admin will have to set the is_active_clr to True

Data Model Changes

• Create new table GrantType

pk	type	is_clr_active	total_pot	threshold	start_date	end_date	prev_round_start_date	prev_round_end_date	round_number	logo	next_round_start_date	next_round_total_pot

• Update table GrantCategory

pk	grant_type	name

• Update Grant model -> to reference newly created table
• Add a custom migration to update grant data to link

Frontend

• Each Grant Type would have it's own URL https://gitcoin.co/grants/<GrantType> This is already supported.
• Personalization helps -> need to make a unique banner for Grant Type https://gitcoin.co/grants/matic with a logo etc to make it stand out This again would be controlled via GrantType Table

Backend

• Update code in views.py to avoid using constants is_clr_active and instead using data from
• Remove all the hardcoding from clr.py and instead fetch data from newly created tables.

Others

• Replace multiple cronjobs and instead have a single cronjob which would run all active clr_rounds ( this means in would be sequential )
• Could use celery but not sure how we'd fire a task only if that round is not in queue
• Could explore something like parallel processing

from a data eng perspective: w/ my limited knowledge lol

1. I think having the round number is a fucking godsend, especially if you look at the hack shit I've been doing in metabase 😂
2. I think kevin's fk to previous and next round in grant_type (or grant_round?) would be great when doing self joins to figure things out with the possibility of 1/3 contributions. Alternatively, why not just have a single entry every time a grant shows up in a different round, and we just self join on grant_id or filter on grant_round?
3. agree that grant_category should be disconnected from time bound vars.
4. can we have an example about: "a grant type can have multiple categories", these terms sound very familiar.

from an analytics perspective, our main goals are:

1. num of contributions by grant
2. total contributions by grant
3. clr calculations by category, by current round, and by previous round