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

makes rough sense to me. instead of prev_round_start_date/ prev_round_start_end why not have a pointer to the previous round + get it there?

if it were me, id have GrantRound, GrantCategory as the models.

GrantRound

• title
• round number
• start date/end date
• amount in USD
• fk to Grant Category
• prev_Round fk to GrantRound
• next_Round fk to GrantRound
• logo

GrantCategory

• name
• parent_cartegory, fk to GrantCategory
• grants (many to many fks to all grants in that category)

this accomplishes two things

1. allows us to make categories nested
2. seperates the concerns of the time based things from the taxonomy related things (categorization)

@owocki

Are you talking about Grant Category / Grant Type ?
A Grant Type has multiple Grant categories !
It's a shitty naming but since this was bountied out as with that as the name.

Having the GrantType link to itself offers a lot more flexibility than we need.
It makes things confusing when you have tech grant type which has categories which is fk to GrantType itself

Keeping it segregated I feel keeps it cleaner as it becomes evidently clear from data that every GrantType can have a CLR but not a GrantCategory.

A Grant Type can have multiple Categories but not vice versa
A Grant Type can have a CLR associated with it but not a Grant Category

---

Having the GrantRound also is another way to go but we'd have to create an extra table for it.
It might help keep track of earlier rounds in terms of when it happened but I'm not sure how much use it would be

My thought was at any given point in time -> a GrantType will have only 1 CLR round possible so as to avoid creating new rounds and stuff. Hence the tight coupling btwn a CLR round to the GrantType

The previous round fk link does seem nice as the admin wouldn't have to recollect when the last round which is an inconvenience
This I open to based on what the others feel 🙌

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