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
Grants 2.0
(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
tech stack
architecture
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.
I agree with the public research and development process, @thelostone-mc! The way @timbeikodocuments the Ethereum core research and development updates might be a good role model as we build Grants 2.0.
That level of transparency might be super valuable in onboarding new Gitcoin and partner engineers to contribute to and build on top of Grants 2.0.
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.
Many thanks, Tim â this overview is super helpful!
Iâd be delighted to walk you, @kevin.olsen and @lthrift, and the Grants 2.0 team through this map and showcase examples of the different Ethereum AllCoreDevs âresolutionsâ for our consideration.
Iâve always found a codebase/library more approachable when a strongly typed language was used to develop it. I feel like type hinting can act as a form of built in documentation.
I also feel like simple tutorials outlining use cases can make projects more approachable to all levels of developers
Thank you for sharing your insights, Kevin.
And sorry if my answers deviate from what you are looking for, but I wanted to add some suggestions.
How can we make developers first-class citizens of Grants 2.0?
I think that giving the possibility to fund grants with developers hours could be helpful:
As a developer, I want to fund a grant with X hours per week for Y months.
As a donor, I want to purchase hours from a developer to fund a grant.
How can we enable a thriving ecosystem built on top of GitcoinDAOâs products?
Arranging a hackathon around some products with workshops from the teams, and ideation sessions could be a good start.
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?
I really enjoyed this discussion about the importance of DevRel in the Web3 space. It happened this morning. https://twitter.com/i/spaces/1LyxBoBdYmkKN?s=20. I can definitely see the need for this position at Gitcoin.
dogg fooooodinâ
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?