The objective of this thread is to start a conversation. What should the developer relations practice at Gitcoin look like?
Here are the projects that need developer relations I’m aware of at GitcoinDAO 2022.
Proof of Personhood Passport
(any other GitcoinDAO software products on the roadmap which need a thriving developer ecosystem)
I’d welcome corrections from any workstream leads on the above list. The above is just my best approximation of the products on the roadmap as they currently stand in the DAO.
I know that in Grants 1.0, our documentation was quite paltry - it was hard to find, we did not invest a lot in making sure it was updated, and there is generally not a very thriving developer ecosystem built around Gitcoin’s APIs & open source code (though the gitcoin.co product does have plenty of active users, many of them are developers).
We have an opportunity to reset this as we transition from company to DAO, from Grants 1.0 to Grants 2.0. So here is my prompt to you:
What does good documentation look like?
How can we make developers first class citizens of Grants 2.0?
How can we enable a thriving ecosystem built on top of GitcoinDAO’s products?
As we all know from the Grants 2.0 post, “Once grants 2.0 is launched, we will have created an environment where the community can test different public goods funding mechanisms on top of a deeply liquid registry of grants.”. What will that community look like? Where will we find them? How will they be enabled? How will they be incentivized? What kinds of tools will they build? What kinds of new innovation will be unleashed in mechanism design by this ecosystem.
I’d be curious if people in the community would be interested in putting forward a proposal to the DAO to formalize a developer relations practice at GitcoinDAO (which currently resides in multiple different groups at varying levels of coordination)
One area I think there is possibly an opportunity is to form an area of practice around Developer Relations which spans across different proucts/workstreams.
While this deviates a bit from this post → Since we talk about documentation
Having an index of all research stories → not just how the product works but also decisions relating to
to be documented and shared.
The purpose being a lot of this material could provide context to other workstreams if they had to make a similar problem to solve. Something as trivial as what’s the most reliable network to deploy on / web3 service provider to complex decisions like where to dStorage would be helpful
While regular project / product documenting is required / helpful.
Having this information shared within the DAO → would enable other projects to take advantage as opposed to re-inventing the wheel.
Chiming in because I was tagged! I think for ACD specifically, having multiple “resolution” helps different parts of the community follow the process.
Depending on how much attention you want to give, you can:
Spend every day in the R&D discord following the latest changes (mostly client devs + researchers)
Attend/listen to ACD calls in full or read the entire transcript (forthnightly)
Read my Tweet thread summaries of the calls every (forthnightly)
Read my or Danny’s blog updates about things (every 1-3 months)
Wait for official network upgrade announcements on the EF blog (1-2x per year)
While these might not map perfectly to your context, I think having a couple different “resolutions” aimed at people with different levels of engagement is a good overall approach if the overhead isn’t prohibitive.
Indeed, hackathons seem like a natural fit to engage developers with Grants 2.0. Something like the GitcoinDAO Hackathon, which I proposed a while back, might be a good framework for judging and rewards: GitcoinDAO Hackathon 2022.
Relatedly, @brent brought up "Moonshot Collective speed hackathons.“
Besides hackathons, I could also see Grants 2.0 specific quadratic funding grant programs to fund related development work.
very much agree with this point — I think really good documentation is nested in a way that enables people to easily skim OR drill into the details. I like to use the 1 sentence, 1 paragraph, 1 page framework for this: does the reader need the one-sentence summary of the idea you’re communicating, or do they need a page’s worth of detail?