@Gus have mentioned an idea yesterday about moving official foundation grants process to Github & pairing it with Sputnik for payouts.
Using PR process on github to apply is familiar to people, doable via Github UI and creates more transparent in the process. Allows to bring external people to review submissions easily. We also right away can get their NEAR account for a payout. Payouts in NEAR and stablecoins then can be done via Sputnik DAO.
Pros:
We create more transparency
There is more peer pressure on delivery,
We can starting including more people from community, request-for-grants can literally be PRs that other people clone and fill out. Ideally, this will allow us to have both more grants, faster approval process, higher delivery rate.
Including it would be easy to see which community members support a project, as you can just gather likes or comments from the community on github.
Cons:
applying in the open may dissuade some people as they need to tell exactly what they doing to the world. A way to address is to allow to attach a private document to the PR. This is less convenient to dissuade people but still allows to list more details if project is not ready to share.
other projects approach our grantees. Honestly, I don’t think this is the problem right now - we actually have less grant applications already than others and many projects applying to all grant programs they can. Going forward we should just be working with people who want to work with us, given we have better tech and they can actually build stuff that normal people can use.
UI is not as convenient, as Submittable allows to track a number of steps in the process and allows better evaluation by team before giving answer to the team. There are few things here, but I think main one that this transition will come with process simplification where this tracking is not needed. Also can use an email thread per PR between a grants@ to capture notes before grants review meetings for something that is complex (though there are only a few grants that actually require that level of scrutiny).
…To elaborate, in the short term for testing this model out, I see we start out with:
Target group / grant type
Pure open-source developer & product related grants (to counter any privacy concerns)
Funding type
Payments only in NEAR or wUSDC / wDAI payments (to counter any FIAT or lockup hickups)
Approval process
To be eligible for payouts a developer would have to showcase what they’ve build in the form of a code walkthrough or other type of product demo (to counter any review / approval bottlenecks). We would setup a dedicated video channel for this.
DAO Council
Initially the DAO Council will be me and other interested from the community. We would setup an incentive structure for all council members as well.
Publishing / Promoting each submission
We publish each submission in NEARWEEK and retweet from official channels. If a developer / project is interested we also arrange AMAs and intros to other projects. Using a tool like sourcecred we will also remunerate this type of value adding activities.
NEAR Developer Fellow Perks
Each grant recipient receives limited “NEAR Developer Fellow” swagg from store.near.org & joins a closed group of other developers / projects who have gone through the programme.
Governance of Grants DAO
I think we should use https://tokenlog.xyz/ to let members of Grants DAO vote on which developments / upgrades should be used to the Grants DAO. Using Spuntik v2 native token we can allow such voting mechanisms.
…Some thoughts for more “crazy” long term ideas
Challenge submissions
To make the whole review / approval process more scalable I think we should look into “challenging” type of models where other 3rd party developers can challenge submission and get a large part of the grant this way.
Quadratic Grants
I think we should very fast experiment with quadratic type of voting which is used in Gitcoin grants, this way we allow developers to vote on which projects have had the biggest impact
Conviction voting
To put in place staking type of mechanisms, we can allow confident developers to stake on their own submissions to be able to net a higher grant, however if other challenges this they will loose all of it.
DAO Reputation
Use a https://metagame.wtf/ type of player / reputation system to track individuals contributors throughout all NEAR DAOs (including ofc this DAO here).
Social Graph
With these building blocks above I believe we are ready to then utilize social-graph to make the whole model more scalable. This includes developers for-example starring each GitHub repos, having approved pull-requests, helped out with questions via sourcecred type of remuneration forexample via Discord etc. etc.
The direction to transparency sounds good. It also sounds like there are bots that can create email notifications for state transitions, which is one of my major concerns (since notifications for applicants is one of the biggest ball drop areas).
It’d require more project management by the grants team perhaps but tbh maybe not so much more. Not sure how it affects scheduling interviews and collecting feedback.
I think it is an interesting idea to move grants to Github and it definitely worth to be tested. The idea to have a video demo of all app’s features where the author explains how it works is nice too.
What about the near-bounties? Is it use the similar approach as @Gus proposed? If so, can we investigate the existing experience with near-bounties and use it for the decision?
I think this could address the situation of duplicate efforts. We’ll sometimes see grants aiming to solve the same problem. (For instance, a token standard in AssemblyScript.) This would give the community an idea of what’s already being work on before they spend an afternoon writing a proposal for something that’s in-flight.
Also, I’m already dreaming of SpunitDAO v2 integration with a GitHub bot, similar to how Gitcoin has a slick bot to assist with the progress of a bounty.
I think having a DAO structure to support smaller grants sub $20K makes sense since it would streamline the process and increase velocity. Looking forward to discussing this in greater detail with Gus and others next week. For some larger more complex grants I do think its important to have a more BD like process.
With respect to transitioning to github. We are going to be experimenting with a join grants program with Filecoin that will leverage github. I think we will develop some learnings here to support a more direct transition. One thing I worry about is that it may discourage some of our grant applications from creators and educators who are target groups that make up a significant number of current applications.
@robert This is an open question I have discussed briefly with Cameron. I think it is important to understand what our broader strategy is with bounties before committing to use Gitcoin or another platform.
Imo no downside of integrating Gitcoin asap, not aware if there are any blockers to make that happen. Bounties & recurring grants works very well on Gitcoin.
Love the idea of a Github-based grants flow. I ran through the “open” Filecoin grant process and “closed” alternatives before, and can confirm the advantages. Transparency gives you an idea of what other teams have built, of scope, and it speeds the whole process up.
I do like Gitcoin, too. So how about we build our own Gitcoin, on NEAR? I could see a scenario where even Ethereum bounties run over NEAR contracts, especially for small payments. Which ultimately is a nice niche for NEAR to be in and onboard new developers.
And to get started, I could build a first version with a small team.
We recently built this DApp on NEAR testnet (https://near-testnet.betterhq.org/) which uses Sputnik v2 contracts to manage bounties for DApps, and which we could extend to integrate into Github.
We also built a prototype that stores bounties in Github (including tags and metadata) and mirrors them on a website that allows for voting and funding. (Link to site, Link to Github issues )
We just built a new version of our Github-based bounty platform, which could scale a NEAR Ecosystem DAO and automate the grants process through Github.
