Discussion: Community Input on GR13 Structure

[annika]

Hey everyone,

The Public Goods Funding workstream would like to seek community input on what folks would like to see in terms of structure for GR13.

GR13 will run from March 9-24, 2022.

Context

In prior rounds, the distribution of the Grants Matching Pool had been handled by the Gitcoin Core team (rounds 1-5), and later in consultation with the Funders League (rounds 6-9).

In GR10-12, we moved to having distribution based on GTC governance, with matching pool allocations voted on by the stewards a couple weeks prior to round start.

For GR13, as we continue on the path of decentralizing Grants Ops from Holdings into the DAO, we want to build the habit of bringing the community in much earlier in the process to provide their input on what they want to see with respect to the matching pool, rather than having a Holdings-proposed structure that stewards simply vote on.

This post is an experiment in that spirit!

Structure of Prior Rounds

Prior to GR12, Gitcoin had typically used categories based on grant types to assign allocations based on a percentage of the total matching pool. More details in the GR12 governance post.

In GR12, we ran a ‘Single Pool Experiment’:

The GR12 main pool will be a single matching pool fund/distribution of $1,000,000 in matching for the round. No individual grant’s matching contribution amount shall exceed 2.5% of the overall matching pool fund (i.e., $25k).

GR12 results to assess for yourself:

• Finale event (with discussion of results)
• Results post
• Spreadsheet with raw data

Questions to the community

• What do you want to see when it comes to the main matching pool in GR13?
• Is there appetite to bring back categories or do folks want to stick with the single pool approach from GR12?
• Is there any other experimentation that folks would like to see?

Your input is appreciated. Thanks!

[tjayrush]

I’ve been on a few boards of directors in real life and also a member of non-profit organizations, and one thing I can say is that when an organization starts repeatedly asking for funds I start to get a bit annoyed. And that is especially true of organizations that ask multiple times a year. (I’m just sharing my real-world experience.)

I feel like it might be beneficial to grant recipients (such as myself) if the grant rounds were either (a) spread out in time, (b) spread out by category.

For (a) what I mean is that the grant rounds could be twice yearly or even annual. I’m already seeing some donor fatigue, not to mention it feels like the previous round just ended and I’m constantly “on the ask.”

I’ve been told by close friends in private that it seems like I’m constantly asking for funds. But…if I don’t ask…my donations drop off precipitously. I realize that I could choose to simply not participate, but I’m not sure that’s the intended design of the system, plus if I drop out, getting back in later is that much harder.

In the case of (b) (spreading out by category), I feel like this is something we might experiment with. So perhaps the first quarter of each year is NFT and DeFi quarter. The second quarter is Infrastucture and Identity quarter. The third quarter is X and Y quarter…and so on.

In this way, any individual project would only have to focus once a year and have more time to focus on a clear messaging/marketing strategy. Also, each project would be competing in a smaller “world”, so the donors might more easily find projects that they might not find otherwise. Also, the matching fund donors could ‘specialize’ and only match funds for particular categories more easily.

I’ve made these suggestions earlier, and I understand that momentum is a powerful thing, but I make this post to gauge whether anyone else is experiencing this ‘donor/donation fatigue’ that I, and maybe parts of my community, are feeling.

As always, my comments are intended to be helpful, not critical, so I hope they are taken that way.

Cheers.

[lefterisjp]

If that were to happen though we would need to have bigger matching pools as currently the idea of a gitcoin round is to get you through a quarter. You would need roughly 4x the funds raised, so I assume also 4x the matching pool to make it through a year.

I concur on the fatigue. It’s draining. It’s amazing help though as someone whose project has indeed benefited a lot from gitcoin grants. Wouldn’t mind it being less frequent, provided the matching pool size was also adjusted to make up for it.

[tjayrush]

I’m not sure that’s right.

Right now each grant potentially gets TotalMatch / nGrants in all categories and I’m suggesting lowering the number of categories which would naturally raise the amount of potential matching funds available to each grant in the remaining categories.

Are you saying it makes things worse related in some way to the quadratic funding even if there are fewer grants participating in a round?

[lefterisjp]

no that’s not what I said. I am saying the aim of gitcoin grants funding so far has been to raise funding for projects for a quarter. Not to raise as much money as possible.

If we do it less frequently we would need to also have bigger matching pools.

[Anyway this is getting offtopic to the questions posed by Anika so I can clarify more if there is something you don’t understand via DM]

[anneconnelly]

I came from the traditional charity fundraising world and repeated asks are the norm. As you say, if you don’t ask, you don’t get a gift. I don’t agree about running specific themes once a year, it puts teams at a significant disadvantage if their timelines don’t match the schedule. Having the grants round is also a stewardship opportunity to feed back to the community that supported you.

One way the regular charity world gets around the repeated ask problem is to sign people up for monthly recurring donations. I think many donors would be happy to say “I’ll give $2 every grants round automatically”. We would just need to add that funcitonality.

I like the idea of categories to highlight project themes or two enable better searching (it’s much easier to say, I want to support projects based in Africa and have a category for it rather than scanning all of the projects), while leaving the round open to anyone to participate.

Donors also tend to give small amounts each round because of the matching. I think if they only had to opportunity to give once a year, you wouldn’t see those $1 donations turn into $10 donations.

[anneconnelly]

Happy to jump on a call to discuss more about strategies from the old world that could be implemented here.

[kyle]

Thanks, Anne.

I tend to agree with you the on the sentiment. One of the intentions when we first set the quarterly cadence was to ensure a project could be funded with a Gitcoin Grant for as long as they were active. The Gitcoin Core team has had an internal metric of trying to grow the number of grants that receive more than $5K USD in funding per round. This $5K number has been a watermark for whether or not funding received was sufficient to “change a dev’s life” and enable them to build and work on their project in the open web.

I worry that any lower in frequency (less than quarterly rounds), we may see accountability of projects drop off. We already have problems where folks get funds to do something and then don’t deliver. Having accountability checks but once a year seems like it would perpetuate that problem. Also, if someone misses the NFT round by a couple of months, it would be devastating to know they have to wait nearly a year before they would be eligible again.

@annika - In the spirit of your question, I wonder if there is an opportunity to smooth some of the funding that has come in from the side rounds too. There were some pretty large matching pool amounts paid and I am wondering if that is a feature or bug. ie, should someone take $250k of a $500k matching pool?

IMO, the goal of the matching pools is to encourage work/project development. Having projects get very small matching contributions because another project is getting a large sum is often discouraging. On the same hand, we often tout how successful some projects are based on their large matching fund grant. I am curious to get other’s thoughts here.

[anneconnelly]

I guess we need to look at the underlying goals of the program as well. Is this just to kickstart projects to help them grow, or is it also to support longstanding projects that might be able to get funding later (or solicit funding from their own user-base). If it’s the former, then we should look at a maximum amount of matched funding they could receive in the lifetime of their project or per round. You could still allow them to use the donation functionality of the platform, just not let them tap into the matching.

Accountability is definitely critical. I wonder if there’s a specific project update form that would be required to get filled in before a project could opt-in to matching funds during each round. If you don’t report back on what you did and describe what you need more money for, you don’t get included. The question then is, what constitutes a “good enough” update to qualify them?

[kyle]

@anneconnelly

then we should look at a maximum amount of matched funding they could receive in the lifetime of their project or per round. You could still allow them to use the donation functionality of the platform, just not let them tap into the matching.

This is an interesting idea. Historically, different cause rounds or ecosystem rounds have not had a cap, like the main round did of 2.5% in GR12. I wonder if we could set a default of a 10% cap unless an ecosystem wants to specifically remove or adjust the cap.

@anneconnelly

I wonder if there’s a specific project update form that would be required to get filled in before a project could opt-in to matching funds during each round.

This kind of happens now in the UI as “inactive” grants are not visible in the explorer/search results. A grant is marked inactive if they have not updated their description in the last 3 months. The implementation of this has been a bit clunky and community members ask “why cant I find Grant XX… Gitcoin is broken” when we really want the perception to be “Why hasn’t a grant been updated in over 3 months? What a deadbeat, I am not going to fund that! Thanks Gitcoin for flagging this to me.”

[annika]

@anneconnelly - thanks for your thoughtful responses, would love to take you up on a call to chat about strategies from the old world and get your feedback on how we’re thinking about recurring commitments. I’ll DM you on Discord.

@kyle - to answer your question:

@kyle

@annika - In the spirit of your question, I wonder if there is an opportunity to smooth some of the funding that has come in from the side rounds too. There were some pretty large matching pool amounts paid and I am wondering if that is a feature or bug. ie, should someone take $250k of a $500k matching pool?

I think there’s definitely an opportunity here. @connor has actually been discussing this already with ecosystem partners in advance of GR13. We should revisit matching caps in the context of the cause rounds too (cc @M0nkeyFl0wer).

And finally - on project updates:

@anneconnelly

I wonder if there’s a specific project update form that would be required to get filled in before a project could opt-in to matching funds during each round.

I think this is a really good idea. To @kyle’s earlier point, it does kind of happen with the requirement to update their description, but I think we should work towards making this even more ‘project-update’ oriented vs. just ‘update your description to make sure it’s current’. In short, a forcing mechanism for grantees to report on what they’ve accomplished since last round and convey that to the community.

[erich]

The Gitcoin Grants “main round” does not fund public goods principally as “main” implies. Instead, it operates in the Ethereum community, if I understand the official eligibility criteria from Gitcoin’s Fraud, Detection, and Defence workstream. FFD is not just defending the main round against non-human attacks but moreover, e.g., against non-EVM/Ethereum and for-profit projects. I’m not sure these are the specific rules. Still, in any case, there are a bunch of eligibility variables like this. Correct if I’m wrong, @DisruptionJoe and @Sirlupinwatson?

If we acknowledge eligibility rules like this, then “main round” is probably a misleading coining for what’s actually happening. This mismatch most likely increases the number of illegible grant applications, FDD’s workload, confusion for grant recipients and funders, et cetera.

Moreover, as @GlenWeyl noted recently, Gitcoin “is not really a global system.” Indeed, the Gitcoin Grants “main round” is an ecosystem program to fund non-profit Ethereum projects or something along these lines. It’s not a general-purpose program for “public goods.” And that’s precisely why we have scaled the main round program so meaningfully. FDD has sufficient knowledge of the Ethereum community structure to apply bespoke mechanisms to police collusion and potential authentication fraud of funders/earners who try to game the system. (In contrast, strategic collusion/identity fraud are inevitable problems that truly global/individualistic Quadratic Funding programs would run into.)

In turn, philosophically, we might better embrace and communicate a vision more faithful to what we do: Gitcoin builds ecosystems. Yes, bold notion on the plural.

Similarly, the Uniswap grants round we operate is not a “main” round. Accurately, we’ve been calling that Uniswap program on Gitcoin Grants and similar programs like the “Climate” and “Longevity” rounds “ecosystem rounds.”

Hence my proposal: Let’s consider rebranding the Gitcoin Grants “main round” to “Ethereum round,” and with that, we can probably get rid of the “main” versus “ecosystem” dichotomies more generally.

Also, please allow me to loop in Gitcoin’s Memes, Merch, and Marketing workstream (@seedphrase, @Fred, and @seanmac) because this is very much Grants Round structure marketing territory.

[seanmac]

Your thoughts here make a lot of sense, and we’ve had similar discussions in the past months.

We decided not to make major changes to naming for this round but this discussion is definitely not over. Definitely agree with you that we build ecosystems, not just one, and with this our round naming must continue to evolve! Let’s talk about this more this week?

[tjayrush]

@kyle

Having accountability checks but once a year seems like it would perpetuate that problem.

This is a very valid point. I agree with this.

[tjayrush]

@anneconnelly

If you don’t report back on what you did and describe what you need more money for, you don’t get included.

I really like this idea. I’ve been thinking a lot about putting a higher bar on grant recipients. Perhaps we in some way lose “permissionlessness”, but it would make other things (fraud detection for example) easier perhaps.

[reza]

i learned about gitcoin(in a hard way) when i was looking to fund my project(which had nothing to do with crypto). i have been hacking on gictoin for almost 2 years and have participated in more than 6 grant rounds. i do not have specific stats on how much non-crypto grants are making but i guess the majority(maybe > 70%, correct me if i’m wrong please) of the allocation still goes back to crypto projects. while this sounds great i suggest we allocate a specific pool for projects that really have nothing to do with crypto but are crucial as tools/libs to keep web3 infrastructure up and running.
a panel of judges could be formed to select , say 10, public goods projects and send them like $5k or more in >=1 installments. finding those projects is rather easy: just clone any web3 project and do npm install or yarn and see how the terminal output is populated with terms like project x needs funding. these projects are already vetted otherwise people would not have used them so this not a blind airdrop to anons. so many great projects out there and they are really struggling to keep themselves fed. this has also the benefit of growing non-crypto user/funder base too.

[muratgozel]

As I’m in MMM for about 3 months, I still learning the grants structure and want to share my opinions about it. Also curious how my learnings will evolve by time. A Flexible Design for Funding Public Goods proposal was really helpful to learn about public goods and the origin of the idea. Except the equations My input won’t be specific as much as the inputs above obviously. It can be considered as input about grants structure in general.

My first impression of Gitcoin Grants was people place their web3 bullish projects and get funded by bullish web3 funders. As I hear “public goods can be anything, it can be fresh air, open source software…” more in the community I researched more.

What we want to refer to as public goods is what countries do with our taxes actually. But countries have template for it. Hospitals, schools, parks etc. these are all evolved by time and became like a template for anyone who wants to setup a nation. In web3, we don’t have such template obviously but we have reasonable amount of people that suffer in traditional world and can leave their input for public goods. I see there was an attempt here to find ideas about public goods. That’s a great start I think but I concerned about how we handle/process the whole thing.

1. Even some luxury fashion brand send its employees to different countries to design new clothes and create new trends. As we all online, why not regularly collect requests about public goods from related persons/organizations? Similar to the what we previously did but in a massive scale. There may even be a squad for that. Currently, it looks like we left the whole thing to the web3 community. Sounds like dangerous :))
2. Current structure and our message looks like attracting degen web3 people. I know we try to filter them manually. However, I would split this “create grant and get funded” process into two subjects. People who express their request for a public good should be different from people who will actually make it. My point here is to make web3 more familiar with everyone. This way we may have more grants in variety and may slow down eager builders.
3. I see there are categories like infrastructure, dapp, blockchains etc. These all look technical to me. Why don’t we have categories by function such as healthcare, education etc. and user experience can be specific to those categories. I can create some infra tool for education for example. Functional category > Technical category. Each functional category has its own specific needs. So each of them should be handled in its own way.
4. QF is a good idea in general but distribution of funds needs more work I think. I don’t place a specific idea here about that but I know some charity organizations send funds partly on a regular basis.