Decentralized Futures: Ecosystem DevRel Team for Polkadot by PaperMoon


Polkadot was built on creating a decentralized blockspace-centric infrastructure for applications to be built on top of. This results in a fruitful ecosystem of key players that must work together for the greater good of the ecosystem: parachains, infrastructure providers, wallet providers, end-user app developers, the developer community, and the general community, among other participants. In such ecosystems: “The whole is greater than the sum of its parts.”

PaperMoon, a core Developer Relations contributor to Moonbeam for almost four years, recognizes the intricate dynamics and understands the major pain points (as an ecosystem team) of being part of a highly diverse ecosystem. Our proposal is focused on enhancing collaboration, knowledge-sharing, and overall efficiency for all ecosystem participants.

Consequently, through the W3F Decentralized Futures program, PaperMoon seeks to expand its team to provide specific Ecosystem Developer Relations (Ecosystem DevRel) solutions targeted at Polkadot ecosystem participants. The goal is not to provide general Developer Relations services to external teams but to focus on addressing Polkadot’s unique needs, always from the angle of an ecosystem team. Consequently, the Ecosystem DevRel team will offer solutions that bridge communication gaps, enhance understanding of key features and how to apply them, create a knowledge-sharing platform of tools and SDKs that lack proper documentation, and streamline developer feedback processes, with the ultimate goal of reducing the friction for developers who want to build and are currently building on Polkadot.

As Dr. Gavin Wood said, “You need to make it functional right so it has to actually do something that’s useful for people”.

We appreciate the valuable insights the community can provide on our proposal. Constructive feedback is vital in enhancing our proposal to serve the Polkadot ecosystem better.

But First… Who Are We?

If you just heard about PaperMoon (site under construction) for the first time, don’t worry. PaperMoon has been working quietly “behind the scenes” in the Polkadot Ecosystem for almost four years.

In 2023, Moonbeam made strides towards decentralizing its development, moving from a primary core contributor providing all services (PureStake) to a cohort of multiple teams, where each provides expertise in a specific area. PaperMoon was founded by Alberto in January 2023 as the Developer Relations contributor to Moonbeam. Since July 2023, it has operated as a separate entity offering Developer Relations as a service for the network. Moreover, PaperMoon has been an early Developer Relationship contributor to Tanssi since the project was founded in May 2023.

Alberto joined the Moonbeam team in June 2020. Besides Moonbeam, he has been actively involved in Polkadot-related activities such as the Polkadot Assurance Legion, Polkadot educational series, and online and in-person meetups organized by ambassador communities. He has done many Polkadot-specific presentations for events (Sub0, Decoded, ParisDot, EthDenver, EthCC, LisCon, Token2049, SmartCon, and others), hackathons, community meetups and ambassador groups in USA, Europe, LATAM, and APAC.

Even though PaperMoon was founded in January 2023, part of PaperMoon’s stellar minds have been with Moonbeam from the beginning, in Developer Relations and Developer Community-oriented tasks. Consequently, the team is well aware of Polkadot and its entire ecosystem and has collaborated multiple times with many external teams on Polkadot-related activities and meetups.

Summary of the Problem Being Addressed

This proposal is content that results from gathering feedback from many ecosystem participants such as parachain teams, wallet providers, service providers, core developers, W3F technical educators, Polkadot Blockchain Academy contributors, members from Parity, and community members.

All of the ecosystem participants shared similar conclusions: there are many friction barriers when building in the Polkadot ecosystem.

Some of the key aspects can be summarized as follows.

Technical How-Tos on Key Features

Teams have very little information to prepare them when implementing core flagship functionalities like Crowdloan, XCM, Asynchronous Backing, and Polkadot <> Kusama bridge, among others. Consequently, core ecosystem developers must painstakingly study the core logic to understand the changes and successfully implement multiple tests to add new runtime features. This increases engineering overhead and delays new feature releases. Parachain core devs can, without a doubt, accomplish all of this. However, the current process does not always respect their time, energy, and resource allocation.

Lack of a Knowledge-Sharing Platform and Proper Documentation for Ecosystem-Generated Tools

Today, ecosystem teams can’t find reliable and up-to-date documentation on features built and developed by other ecosystem participants. For example, if ecosystem teams try to use tools like Chopsticks and Zombienet as testing frameworks, they will struggle to find adequate documentation on both tools. This creates a high entry barrier for teams that are not familiar with such tools. For example, wallet teams could use Chopsticks-based forks to test new implementations like XCM transfers, and native staking, among others.

Other examples include the XCM-related library created by the Moonbeam team or how to use other tools like xcm-emulator properly.

No Documentation on Best Practices for Polkadot Developers

At the time of writing, only two teams in Polkadot (Moonbeam and Bifrost) and four teams in Kusama (Moonriver, Bifrost, Picasso, and Crab) have adopted OpenGov, clearly indicating that there is a high barrier to entry to implement the core flagship features, such as this more modern mechanism of on-chain governance.

One core reason is that there is little to no documentation on what best practices to use when building on Polkadot, from building a pallet to implementing an existing pallet, using XCM, and using Polkadot.js SDK. Teams are often either just guessing or learning by doing.

Consequently, ecosystem teams find a lot of friction when trying to do any of the actions highlighted before. For example, OpenGov was introduced in Kusama around November 2022 and Polkadot around June 2023. Ecosystem teams often see it as complex. When Moonbeam implemented it, the team spent a fair amount of time understanding the voting mechanisms and deciding on appropriate approval/support curves. There was a huge amount of engineering work with no clear guidance. Implementing it created a lot of overhead for the engineering team and product, developer relations, community moderators, and other Moonbeam community members.

Lack of Proper Documentation on Polkadot-SDK Releases

At the time of writing, the now-named Polkadot-SDK has had approximately 150 releases since August 2019. While some of them are relatively small, there have still been three releases per month since the first one! The pace isn’t the problem; rather, the lack of guidance and clarity comes with these regular releases, forcing devs to catch up constantly.

Many ecosystem teams (especially parachain developers) experience a common pain point: the engineering overhead generated when trying to stay up-to-date with Polkadot-SDK releases. For smaller teams, this impedes innovation, as most of their engineering resources are dedicated to staying current with the latest releases.

Moreover, many PRs often have misleading labels that don’t necessarily assess the impact of a specific feature on parachain teams. The Moonbeam team has been impacted by this multiple times. For example, a PR to Polkadot related to OpenGov introduced an unexpected change in Kusama that affected many parachains. Nevertheless, this PR was labeled as having a “Low” impact.

Lack of Hackathon Scoping around Core Polkadot Tech

Hackathons are one way to bring new developers to the Polkadot ecosystem. In 2023, Polkadot hosted approximately 16 hackathons with at least nine different partners.

Polkadot has relied on external partners like AngelHack, DoraHacks, EasyA, EncodeClub, HackerEarth, OneBlock+, and others to organize hackathons. These partners do well on the execution front. Still, there is a lack of technical understanding of Polkadot to distinguish it from every other blockchain and coordinate all ecosystem teams under a unified hackathon theme that can result in a successful event. Moreover, they must coordinate with each ecosystem team separately, creating a lot of overhead when organizing a Polkadot-related hackathon.

Throughout 2022 and 2023, PaperMoon (through Moonbeam) participated in many Polkadot-specific hackathons, which lacked clear guidance and cohesion from a technical perspective. Hackathon organizers, in conjunction with hackathon execution partners (mentioned before), did not do a good enough job on topics, either focusing on generic topics that are seen in many other blockchain ecosystems like “Smart Contracts” or “NFTs” or technically complex and niche topics like “Runtime building.”

Lack of Proper Feedback Loop Channels

In Polkadot, it is quite common that feedback to the core Polkadot/Substrate developers is given either through GitHub or, in some cases, the Polkadot Forum. Moreover, feedback is somewhat unidirectional, meaning that the ecosystem participants provide some feature request often addressed or incorporated based on its relevance and alignment with the overarching development goals, without a continuous dialogue or iterative exchange between core developers and ecosystem participants.

While these feedback channels work, they heavily impact the speed at which the ecosystem can evolve, limiting the reach and real impact that feedback can have. It also creates a recurring problem: ownership of ensuring that feedback is received and handled.

Furthermore, there needs to be more prioritization of what is needed from the ecosystem developer’s perspective. This harms the adoption of key Polkadot-specific technologies like XCM.

The Proposed Solution

As outlined above, developers’ challenges when building in the Polkadot ecosystem call for a comprehensive and tailored solution.

To tackle the identified issues, PaperMoon will establish a dedicated team of DevRel Engineers. This team (Ecosystem DevRel) will address the challenges described above, always focusing on the ecosystem team’s perspective.

The team will prioritize the following key areas.

Key Features - Documentation and Knowledge-Sharing Platform

The Ecosystem DevRel team will develop comprehensive documentation (or revamp/repurpose existing ones) around key features and how ecosystem teams can interact. This includes features (but is not limited to) such as XCM, Asynchronous Backing, Core Times, OpenGov, and more.

To do so, the Ecosystem DevRel team will do a combination of active and passive outreach and connect with ecosystem participants on an ongoing basis to understand the status of the ecosystem from their perspective and to prioritize what features need to be documented based on demand. In collaboration with the W3F technical educators, this documentation can be hosted in the Polkadot Wiki so that it is coherent with ongoing structure and can benefit from things like SEO and Polkadot’s reach.

With this strategy, on the one hand, the active outreach mechanism ensures that the Ecosystem DevRel team is constantly reaching ecosystem participants to inquire about the new features they want/need to be documented. Conversely, the passive mechanism ensures that the ecosystem participants and core protocol developers can request certain features to be documented or submit updates to the documentation.

Tooling, Scripts, and Procedures - Documentation and Knowledge-Sharing Platform

The Ecosystem DevRel team will use established communication channels with ecosystem teams so that the tools they create can be shared broadly with other teams building on Polkadot. In addition, all tools will be well-documented, and the DevRel team will ensure the documentation is always up to date.

To do so, and similarly to the point before, the Ecosystem DevRel team will use multiple channels to empower teams to showcase new tools so that the Ecosystem DevRel team can work on documentation for it.

Like before, the Ecosystem DevRel team will operate a passive and active mechanism for this documentation, ensuring that up-to-date documentation does not necessarily require ecosystem teams to reach out or submit the PRs themselves. The team will be responsible and accountable for maintaining the documentation up-to-date as long as the tools/scripts work.

Best Practices - Documentation and Knowledge-Sharing Platform

The Ecosystem DevRel team will ensure there is a source where ecosystem players, including Polkadot core developers, can document (or provide the necessary details so that the Ecosystem DevRel team can document) best practices when building on Polkadot. This does not necessarily have to be for parachain teams, but also developers building infrastructure or services.

To do so, the Ecosystem DevRel team will first connect with all ecosystem participants to understand the current needs of the ecosystem and create a priority-based system to address all requirements. Ideally, the Ecosystem DevRel team can leverage DevRel members from the ecosystem teams or a key contact if there is no DevRel position to address their needs and what needs to be properly documented regarding best practices.

Moreover, the Ecosystem DevRel team can invite Parity core developers to share their tips on different aspects when it comes to implementing certain pallets and substrate coding best practices, among other things.

Polkadot Release Knowledge Center

The Ecosystem DevRel team will work with the Parity release team to understand new releases and help ecosystem teams with the upgrade.

To do so, the Ecosystem DevRel team will plan to schedule regular meetings with the Parity release team to ensure that the core changes of the release are well understood from an ecosystem team perspective.

Once the key points have been identified, they can be shared with all ecosystem participants through public good channels like a Telegram channel via a Bot or posted in a specific DevRel ecosystem knowledge-sharing center section.

Hackathon Coordination

As Polkadot is a fairly complex ecosystem with many moving parts, we believe Hackathons should be coordinated with the help of the Ecosystem DevRel team. The team can focus the hackathon on concrete topics that generate interest in key technologies unique to Polkadot and cater well to different buckets of developers: newcomers, dApp developers, smart contract developers, and blockchain developers. Some examples include:

  • Showcase Specific XCM Use Cases - XCM is widely underutilized in Polkadot. 90%+ of XCM messages transfer tokens between the different ecosystem participants. Moonbeam utilizes some remote EVM calls via XCM, while Oak Network arranges automation executed through XCM. With technical expertise and input from ecosystem teams, concrete XCM use cases can be offered to hackers to experiment and showcase. For example:

    • Allow users from different parachains to interact with specific functionalities from other parachains without switching wallets. For example, a game on Moonbeam, HydraDX’s AMM, and Bifrost’s derivatives, among others

    • Modify existing wallets so that they are cross-chain aware and capable of handling the wallet owner’s computed origins accounts on other parachains

    • Create a voting mechanism that uses Manta’s privacy layer in which tokens are routed through Manta and then used to vote in a privacy-preserving way

  • Create a unique XCM use case that utilizes technology from at least 2 parachains

  • Tooling, Services, and Data Analytics - Polkadot does not only need runtime developers, it also needs people who build tools and services around it. Topics around these areas that are bound to specific Polkadot features like XCM and on-chain Governance can help attract developers

  • Polkadot for newcomers - Create bounties specific to developers who want to learn more about Polkadot and its core technologies. For example:

    • Create a library that interacts with a specific Polkadot flagship product like OpenGov. The idea is that developers learn about OpenGov and how it works, and create simple tools that can help teams: a monitoring mechanism for proposals, a way to track voting tendencies, and a delegation-specific dashboard.

    • Create tools that can load-test ink! based smart contract networks by targeting specific contracts and function calls.

The Ecosystem DevRel team will help organize Polkadot-specific hackathons around ecosystem teams. Moreover, the team can target specific hackathons organized by external ecosystems through partners like EthGlobal. For example, we propose that Polkadot participate in the hackathon component of DevCon 7 2024, which will be hosted in Thailand at the end of the year. Participating in external hackathons is crucial to bringing new developers into the ecosystem, and giving Polkadot exposure to developers from other blockchain communities.

In addition, the Ecosystem DevRel team will provide active support to hackers, challenging them on ideas they want to build, and providing solutions to problems without requiring ecosystem participants’ engagement. They can provide a unique view that is more “ecosystem” centric.

Hackathon coordination will be a joint effort amongst other key players, to ensure it is a coordinated ecosystem-wide effort and boosts visibility and brand awareness. Therefore, hackathon coordination will be a joint effort of the Ecosystem DevRel Team, marketing, and community.

Ecosystem Feedback Loop

The Ecosystem DevRel team will support and assist with feedback from ecosystem participants. The team will use the existing channels (GitHub and Forum) and create new ones through the ecosystem Knowledge-sharing site, or direct communication channels with ecosystem teams.

More importantly, the Ecosystem DevRel team will own the different feedback streams, ensuring they reach the corresponding stakeholders and set recurring meetings to review all the open topics. The team will produce monthly/quarterly reports to ensure the entire ecosystem has visibility into the general feedback of the ecosystem.

An extremely important need is a feedback loop and “owner” from an ecosystem perspective. Polkadot and its ecosystem must cater to smart contracts, dApp, and runtime developers. From an external perspective, Polkadot is seen as an extremely difficult tech to build on top of (not only runtimes!). Therefore, feedback is crucial to ensure other devs have a pleasant experience when building products on top of the Polkadot ecosystem.

Next Steps

We plan to submit our proposal once we’ve gathered enough feedback from ecosystem participants.

If you want to reach out directly, feel free to do so at Telegram: Contact @albertov19


It’s probably no surprise that I’m a big fan of Alberto and his team since we’ve worked together for 3.5 years on Moonbeam. He’s excellent at what he does, and his skills are widely coveted by other dev-focused crypto projects and teams. He and his team (many of whom you would probably recognize) are always front-and-center with teams on Telegram, speaking or at the booth at conferences and hackathons, and even serving as front-lines tech support on Discord Office Hours or in YouTube comments. Cannot sing their praises enough as someone who’s had the fortune to collab with them for many moons.

I would absolutely love if they’re able to bring these same skills to solve some of the remaining dev adoption issues that persist on Polkadot. That said, I’m biased :slight_smile:.

As for the proposal itself, I think we can agree that there’s an underutilization of some of Polkadot’s star features (e.g., OpenGov, XCM) and I cannot see a downside to investing more resources in making these differentiating features more accessible and easier for devs to try out. He quite literally wrote the “how to” guide on deploying XCM as he helped dozens of parachain teams figure out how to connect to Moonbeam using it. I’d love to see these kinds of features live up to their potential & get some real usage outside of basic token movements across chains!

One of the challenges I see is how we organize all this info and whether there’s a way to provide a unified front, so that ecosystem devrel (this proposal) and Parity devrel are working together in tandem in some way. It would be a miss if there were lots of different websites and wikis to check in order to get all this information, which is one of the issues at present.

That said, there’s something really key here that I think is extremely worthwhile which is:

This kind of feedback (or maybe even just reports?) would hopefully serve as a great resource for the Parity engineering team as they’re navigating roadmap and their-ever growing to-do list. How can we help ensure some of the top-requested items from the builder ecosystem make their way onto that list? Seems hugely valuable IMO.

Good luck PaperMoon team!


I’m working as a moderator for Moonbeam’s official channels, and I’ve had the pleasure of collaborating closely with the PaperMoon. they’re always incredibly helpful whenever anyone in our community, including builders and users, has had technical questions or issues. one standout feature of the PaperMoon team is their availability across different time zones, making sure they can assist at any time

In my role as a moderator, I often interact with the Moonbeam community, helping them find the right information to use Moonbeam effectively. thanks to PaperMoon team, they’ve developed a wide range of guides and documentation, covering various topics, both technical and non-technical. these resources act as a valuable knowledge hub, equipping our community with the information they need to succeed with Moonbeam. also, PaperMoon has introduced the bot to the Moonbeam Discord and documentation page, making it much easier for builders / users to quickly find answers. all thanks to our comprehensive documentation, which covers everything about Moonbeam and is a crucial resource for our community

furthermore, all the processes they organize, like hackathons, dev calls, etc, are consistently well-organized and thoroughly documented, ensuring a smooth experience by providing all the necessary info

I want to emphasize that any issues I’ve come across have been promptly addressed by the PaperMoon team. they’ve been quick and efficient in resolving any concerns I’ve brought up. this high level of support has made my role as a moderator and my overall experience within the Moonbeam community much smoother

It’s also important to note that my positive experience isn’t because I’m associated with PaperMoon. feedback from our community members and well-known people in the Polkadot ecosystem consistently highlights the value of Moonbeam’s documentation and how it helps people engage effectively with the Moonbeam. In essence, actions speak louder than words, as the community continues to show their appreciation for Moonbeam’s documentation and preference for working with it

therefore, I fully support the PaperMoon team!

2024-01-24 124142
2024-01-24 124253
2024-01-24 124316


I don’t even need to read the forum post carefully to know this is one of the top-tier proposals that DF program and Polkadot will be successful with in 2024.

Alberto and Papermoon team always explain Polkadot technical information extremely down-to-earth, and always BE PRESENTED to help anyone who want to kick off their careers as Polkadot engineers/developers.

One clear case study Moonbeam Network already has more than 300 integrated applications on the network, in 2 years.

I do 100% support this initiative.


When I started learning Substrate, I noticed the complex multi-level of abstractions. Many parameters are declared in different parts of Substrate primitive libraries and developers can only be aware of those by reading other parachain source code.

The same thing applied to adding pallets to the runtime (which needs to be a seamless process due to the modular architecture of Substrate) produces many absurd bugs which hard to fix as there lack of documentation.

From my perspective, this proposal is extremely needed for the growth of Polkadot if we want to onboard more developers. If there can be a place to help guide developers on how to use the Pallet instead of just relying on the Rust crate documentation is very helpful.

Good luck PaperMoon team!


Worked with Alberto for 4 years - he and his team are top-notch and probably the only people in the world who understand substrate, XCM, and EVM. For any BD efforts to be successful, you need the ability for teams to get support and documentation while building. This is a no brainer for me.


Thanks for the detailed write-up. In general, I would be interested in seeing this proposal succeed, as it does tackle a number of fundamental issues in the ecosystem.

Some comments about individual problem and solution statements.


My observation of Parity’s role in this space is that it is ever increasingly shifting toward core engineering and low level support, which is played correctly, will be a win for everyone, allowing teams to focus on what they are good at while benefiting the greater good. What I am hoping Parity will provide is:

  1. Better source code / low-level documentation [1][2], on key components such as important traits (eg. all currency later ones) and abstractions or FRAME macros.
  2. Better description for PRs and changes, then bundled into a more predictable and organized releases[3].

If you are interested in knowing more about either, feel free to reach out.

I believe the two pillars above would enable then more individuals and teams in the ecosystem to build education platforms and create an exponential snowball effect. It is the components that are needed to “educate more educators”. So I hope it will assist you in achieving some of your objectives.

As you have rightfully mentioned in your description, a lot of key information in this space has so far been spread by word-of-mouth. Perhaps we can name the programming equivalent of it “word of code”.


I also want to raise my support for more ecosystem feedback that is aggregated and delivered to the correct team and stakeholder. I often find myself in need of this information and don’t know how to find the latest version of it.

  1. Polkadot SDK Docs · GitHub ↩︎

  2. polkadot_sdk_docs - Rust ↩︎

  3. ↩︎


Hey @kianenigma thanks for your feedback!

  1. I agree that the Ecosystem DevRel team would have to work closely with Parity to ensure that we can help them with documentation and releases and, consequently, help the Polkadot ecosystem teams. We are already connected in Element, so I’ll reach out if the proposal moves forward to understand more about Parity’s release flow, etc.

I would argue that creating more and more education platforms might impact how effectively we can streamline content for new developers building on Polkadot (and also existing developers). I think the ultimate goal would be to provide the right means for individuals and teams in the ecosystem to showcase their tools to others in the ecosystem.

  1. Agree!

Thanks again for your comments

Hey Alberto - awesome insights here! I think that in particular your documentation of best practices for developers would be warmly welcomed. We’ve developed our own documentation in-house which we’ve shared with our community, and these have been immensely helpful (especially for newcomers). The more the better!

These would then feed neatly into the hackathons, since they are where tons of developers get their first start in Polkadot.

The feedback loops from education, content and best practices would then feed very nicely into this to round it all off.

Looking forward to collaborating together on bringing it all together!


Hey Albero, great proposal and awesome to see PaperMoon coming to life.
I believe that this proposal addresses key problems, especially when it comes to documentation and developer-focused events. I think that having an ecosystem devrel team that focuses on addressing these would be very beneficial for the ecosystem.

1 Like

We have been working closely with Moonbeam and Aberto since our early days. I would like to express my full support for Alberto and Papermoon team with this proposal. I am eager to witness their contributions towards bringing Polkadot and its ecosystem into the mainstream adoption by developers

1 Like

This proposal does indeed cover a necessary portion for ecosystem actors. Decentralizing something like devrel and the actions associated it to me is very sensible - IMHO the best kind of representation can come from here, as they are showing truly actionable usecases :wink:

At a high level, one could split the problemspace of covering Polkadot as a protocol over three portions:

  1. Concepts/topics - relating to Polkadot’s high-level design, architecture, and the nomenclature specific to those things, along with how they compare to other protocols

  2. Lower level documentation catering to developers and builders - this includes initatives like the polkadot-sdk-docs, and guides relating how to use the polkadot-sdk.

  3. Post-builder documentation - we emphasize building out protocols rather than smart contracts, which are more complex to not only create, but also maintain in the longer run. This kind of documentation is crucial in order to keep those within the ecosystem, and to ensure longevity for each protocol that uses Polkadot respectively.

This proposal, as I see it, addresses the third category, which is the most lacking in this space at the moment. Many parachains have spent a lot of time ensuring that they keep up with Polkadot’s developments - a central knowledge base centered around this specifically would be ideal.

warning: personal opinion incoming :wink:

As far as where it is hosted - I’m not sure the Polkadot Wiki would be the best fit for it. Perhaps if the “Build” section was completely redone, then I think it would, but a refactor certainely needs to take place.

I would actually argue to include this in a wider bit of documentation more pertaining to development, i.e., something akin to “”, or similar. This could serve as a general hub for protocol layer maintenance, common pallet implementations and explanations around their respective configuration items, XCM configurations, and other painpoints mentioned.

This would also align with documenting new Polkadot releases and their implications for ecosystem teams - something akin to making clarifications where needed, but also simply maintaining versioned docs (something we don’t do, but should imo). For an example of that, take a look at and the dropdown in the upper left: Getting Started | Yew

One more suggestion to perhaps take into account: when we display something like an XCM config, or a pallet config, I think it would be great to include are the current configurations of different protocols, along with their logic for going that route. This would require something akin to docify, or a CI job to maintain, but would be a nice to have imo!


Thanks for your comments, @bader. I think the Ecosystem DevRel team will have to work closely with W3F Tech Educators and the agents owning the site to ensure that the content our team creates can be logically integrated into the existing one.

Maybe we’ll need to work on restructuring to ensure that docs are split or at least have different “verticals” as needed:

  • End User - just general community, everything that needs to be documented from their perspective
  • Polkadot-SDK Builder - developers building using the Polkadot-SDK
  • Ecosystem builder - developers building on top of Polkadot, but not necessarily blockchains or core dev. For example, wallets, infra, etc. This bucket includes better documentation for things like Polkadot.js SDK, etc.

There is a lot of stuff to work on, which is exciting!