Hi folks –
As you’ve seen already from some previous posts, there was a gathering of some of the key builders across the ecosystem right before Decoded in Copenhagen to discuss various topics. One of those sessions was a huddle of the DevRel folks.
The following are the notes from that session.
Estimated # of attendees: 35
Some of the key participating teams:
- Moonbeam
- Kilt
- Subsquid
- Unique Network
High level discussion points:
The huddle began by asking the attendees to identify their major pain points and discussion topics they wish to use the huddle time to collaborate on. The attendees wrote their points on post-it notes that were then grouped thematically. The themes that emerged were the following:
- Fragmentation of resources
- Lack of collaboration
- Docs
- Finding Experienced Devs
- Underperforming vs Other Ecosystems
The conversation then was moderated to give attendees the chance to speak constructively about each topic and action steps were suggested. The conversation on the fragmentation of resources across the ecosystem managed to take most of the available time with that conversation also incorporating the lack of collaboration across the ecosystem and ways to address that.
Fragmentation of resources (and lack of collaboration):
The conversation in this topic centered on four distinct categories:
- What Parity DevRel can contribute towards addressing the problems of lack of collaboration and fragmentation of resources
- Types of collaborations we can build together
- Ways to incentivize collaboration
- General thoughts
What Parity DevRel can contribute towards addressing the problems of lack of collaboration and fragmentation of resources
- Not every team in the ecosystem has a DevRel team currently or has the resources for such a team. Those teams that do not have dedicated people doing this work may very well fall behind in building developer community and in participating in the collaboration between teams in the ecosystem.
- Perhaps the DevRel team at Parity can help be the bridge for those teams, making sure their voices are represented?
- A strong voice of agreement was offered towards the idea of Parity DevRel offering templates and guides for developer educational resources such as “How to write docs for a Polkadot project?,” a style guide for documentation, and templates for use cases in the ecosystem.
- A single landing page resource similar to parachains.info but geared towards developers and technical users of Polkadot would be a great benefit to the ecosystem. The page could be structured as a map of the journey a developer takes from pre-defined starting points such as “I’m a Moonbeam dev, and I am building X…” and the map connects them to other points in the ecosystem to help make X a reality.
- A regularly occurring forum of all the DevRel and DevRel-adjacent teams in the ecosystem would be a huge benefit to everyone in decreasing the fragmentation and increasing the collaboration. Those meetings should be loosely moderated by Parity DevRel with light facilitation and topics to address decided before each meeting. Each meeting should have actionable next steps, and not only be a place for communal venting, even as that will also be a useful byproduct of these meetings.
Types of collaborations we can build together
- A strong potential area of collaboration is the creation of a documentation resource of x with y content, i.e. “doing something specific (x)” with “a specific tool or tools (y)”. These are short-form technical pieces with no narrative and only helping developers solve a concrete problem quickly.
- We need user/developer journeys prominently displayed on Parity/Polkadot’s websites that show how people can go from one stage to the next – smart contract, dapp builder, parachain, etc. — and showcase the resources across the ecosystem (see the bullet point in Ways DevRel at Parity can contribute for more on this idea).
- As we are all building tooling to help make developers more productive and ease friction in their work, perhaps there are ways we can reduce redundancies in the tooling we create? We are all creating similar types of resources such as wrappers around PolkadotJS, different iterations of concepts like Zombienet, etc. A monthly DevRel huddle call across the ecosystem could help launch a working group to bring a more unified tooling environment to the developers building on Polkadot.
Ways to incentivize collaboration
- Collaboration can be challenging when everyone has their own roadmaps. It’s an ideal but hard to execute in reality. One solution is to put the collaborations in bounties and incentivize it.
- Bounties are a good way to increase the quantity of participation but do we run the risk of decreasing the quality? For example, if we open up documentation to bounties in the community, what kind of checks will we need to ensure that the documentation meets the standards for our respective projects and for the ecosystem at large?
General Thoughts
- Different teams in the ecosystem target different niches within the larger community. For example, Moonbeam has a specific interest in ETH developers. Can we create a regularly occurring forum for these teams to find synergies and create collaborations within their niches?
- First thing is to figure out who we are communicating to, this is what Unique Network first needed to understand, similar to Moonbeam. Need to segregate the info between the business and the technical, and the technical into intro level and expert level.
- What is it that developers want to primarily do? They want to solve a problem. They are usually less technology-first focused, and problem-solving first, and they search for the right stack to help solve the problem. In general, our resources across the system should focus more on the problems developers are encountering and how we can help solve those problems. A lot of what we produce so far are deep-dive technical explorations of the architecture of our projects, etc. but that is only interesting to a subset of the community. To solve people’s problems will address the vast majority of people.
- Lack of collaboration is solved starting with us… the DevRel and DevRel-adjacent in each team. We need to build bridges and learn about each other’s projects, so we can help move developers along in their journeys.
- One concrete benefit of a recurring meeting between all of us in this space will be a chance to share and increase the learning of each other’s projects. The more each of us knows about each other’s projects, the more equipped we will be to help a developer in the ecosystem build across the spectrum of what Polkadot offers.
Action Items:
- Start the work on the shared landing page referenced in the What Parity DevRel can do section of the notes.
- A shared GitHub repository of resources for developers that all the DevRel and DevRel-adjacent teams can contribute to would also be beneficial and highly discoverable for developers building. (Recommended by the Moonbeam team)
- Begin the monthly DevRel ecosystem calls ASAP. (Recommended by a plethora of voices in the room)
Next Steps:
- Categorize the feedback into thematic topics, and share it with the folks who attended via the ecosystem DevRel Telegram channel.
- Proceed to set up and organize the new monthly DevRel ecosystem calls.
General note:
The other thematic topics identified at the top of the session were not addressed as the fragmentation of resources and lack of collaboration occupied the session. Attendees were very animated over these areas and is indicative of the important need to address them.
Each thematic topic on its own could be the subject of a DevRel workshop at a future summit.
4 Likes
Thank you for taking this into the polkadot Forum. We can do a lot as a community to help bring some of these points raised by the DevRel community.
I would love to see this DevRel fellowship spring up and come into something that would help those that are within the community that do not have a DevRel team/Department/single person to bridge that gap.
If we want to start a working group, we should consider what are the agreed action items and points that the group should tackle as we have a mountain ahead of us or a mountain we created ourselves. That is a question in itself. Agreeing on these points early on can solve the conflict in the future since we can decide on a path together. Obviously, we can reflect and reevaluate our course of action in due time.
Seconding the DevRel ecosystem calls to start immediately to ensure the course of action. Since there was minor disagreement about the actions of the DevRel teams, so, it would be good to speak openly about the actionable items that we as a community agree on.
Thank you for starting this post, and I look forward to seeing my DevRel Peers contributing and other community members.
3 Likes
I second that! It is my deep conviction that the DevRel(+adj) need to know each other on a personal basis, need to have a close cooperational realtionship and need to be the superfast path to getting the right info and insights regarding cooperation between chains. Gavin’s model of interoperable network computer only enforces this need to establish these symbiotic models of cooperative operation.
1 Like
I was here at the Summit representing Phala Network. One topic of discussion that was alluded to, but not expanded on was exactly how are teams currently collaborating to build cross-chain use cases. As of today, I am not aware of any projects being able to leverage XCM calls through HRMP channels to build robust use cases outside of Moonbeam’s Remote EVM calls through XCM. Which in my opinion, is the biggest blocker when it comes to building any cross-chain collaborations among the parachains.
Effectively, we are stuck in our silos due to not being able to interoperate with each other bc we either need to open an HRMP Channel or in addition to opening an HRMP Channel, parachains need to implement a custom runtime pallet to be able to efficiently communicate. So now we are left as DevRels to only speak about the opportunities that XCM can offer without any proof or tutorials of being able to build upon the promise XCM offers for trustless cross-chain dApps (outside of DeFi use cases).
Phala, on the other hand, can quickly connect to multiple chains due to our secure off-chain computation model that allows us to run native ink! in the offchain workers and provide HTTP request & derive ed25519/sr25519 & ECDSA keypairs via chain extension. Granted, our solution does not fulfill the promise of trustless execution that XCM + SPREE will provides, but as of today, we can interoperate with Substrate & EVM chains quickly to showcase what is possible with the Hybrid Chain model. There was a great talk by Hernando on the Tech stage at Decoded on Hybrid Chains, and I believe Phala has the most robust implementation of this model with our off-chain ink! Smart Contracts called Phat Contracts.
So in my opinion, if we are able to start connecting chains like Moonbeam, Phala, Astar, Kilt, Unique, etc. through Moonbeam’s remote EVM calls via XCM & Phala’s Off-chain Phat Contracts that can send HTTP requests & sign composed extrinsics for Substrate & EVM based chains then these are the building blocks for DevRels to start collaborating on simple cross-chain use cases today. We are all busy though and taking the time to understand each parachain’s tech can be hard to grasp, but we can figure out effective strategies that takes the least amount of time if we start to plan the format of the monthly DevRel call.
If there are any other mainnet solutions that work today that extend outside of DeFi with XCM, I would like to know as I believe the only other similar solution to Moonbeam’s would be T3rn’s XBI format for ink!. To reiterate, we need more ways to connect the parachains today and make all parachains aware of these solutions for us to engage in collaborating on cross-chain dApps.
5 Likes
I agree we are in our silos. We need ways to work outside the core teams that should provide use cases for others to attempt to build on top of multiple solutions. We spoke about these within the meeting, and we should, as you said, Joshua, take the time to collaborate.
I can say that we have a new cross-chain implementation for providing identities across chains, which was approved by Polkadot governance for the work to implement this generic identity provider. That, in my opinion, can help tie some of these cross-chain use cases. So, thank you to the community, as we can provide the KILT DIDs through this mechanism, along with other identity solutions from other parachains.
Bringing our expertise together and coming up with use cases should be fun and productive only if we can agree on where that information should live. I know that the Parity team has many websites.
Can someone suggest a house for our ideas?
Is there somewhere to set a poll for the meeting’s first date? Do we agree as a group, or does someone take the initiative to set it up?
Would it be more important that the Parity DevRel team make the meet, or can the others begin the polling?
1 Like
Hi all, this is Zsófi from the Parity DevRel team!
Thanks @bengreenberg for posting the notes here!
As mentioned in the summary, the huddle started with a post-it session, where we asked participants to write down their challenges, pain points and discussion topics.
I have created this jamboard of these post-it notes and categorized them.
As next steps, we are asking devrel folks in the ecosystem, or those who are engaged in devrel activities in their teams to take a look and prioritize the post-its from their own perspectives in the coming weeks. Once we have a prio list, we’ll set up a regular call to continue the discussions and come up with action points that can help resolving these challenges.
Parity’s DevRel team is happy to organize and facilitate these discussions in the future, but as the discussion points came from the community, and we are just a small team in the ecosystem, we’d love to see that the work of the collective becomes as collaborative as possible, and in time the community would take over its organization. Wherever we can support the goals, we’ll do that of course.
4 Likes
Hey all,
It’s so exciting to see the discussion on this post and the agreement to move forward with starting ecosystem devrel calls as soon as we can and to kick-start our efforts for greater collaboration.
As Zsofi said, it would be great if folks could prioritize the post-it notes in the jamboard link she shared a day ago, and then we can go from there.
Let’s do this! 
Ben
Alberto | Moonbeam
Thanks for the meeting notes.
IMO - two of these points are crucial to increase the overall effectiveness of DevRel within the Polkadot Ecosystem:
- The page where developers can learn what each parachain can provide for their dApps. Imagine someone is building a Smart Contract based application and want to access “Automation”, then in this page they can see that Oak Network offers that
- The monthly huddles or meetups so that each team presents a 5 min summary or less of what cool features they’ve introduced that is useful for other teams (either via XCM or just a general tool). Out of these huddles, maybe there can be separate meetings for follow ups. For example, we’ve created a really cool tool to emulate OpenGov proposals, in my 5 min I can say “we’ve created this tool” but then schedule a follow up with the interested teams to actually show the tool etc
Great to see this moving forward
5 Likes