Decentralized Futures: Accelerate Polkadot (Goal-oriented, code-first, in-depth guides)

Ecosystem
1

For the complete proposal including all references, links, and images please see the Accelerate Polkadot Proposal doc

AP Logo

1. Project

Accelerate Polkadot

An educational organisation which creates goal-oriented, code-first, in-depth guides on building practical applications within the Polkadot ecosystem.

1.1 Overview

Problem Statement

For developers new to our ecosystem, getting started building with Polkadot is often confusing, convoluted, and intimidating. Existing tutorials are frequently outdated or broken, and most assume the reader has esoteric and domain-specific prior knowledge. This experience frustrates developers and often causes them to leave the Polkadot ecosystem entirely.

Accelerate Polkadot aims to fix this developer onboarding problem by creating bundles of educational content, each of which will guide developers in building examples of real-world applications for the Polkadot ecosystem.

“I have never successfully completed any of those [substrate io] tutorials on the first try.” (comment from a Parachain CTO at Sub0)

At conferences, meetups, hackathons, PBA, community calls, and social media, we have consistently heard the same question/complaint from developers: how do I actually build something with Polkadot?

The substrate io tutorials—which are frequently broken—end too soon. Developers are left with a running node but no direction on developing it into something useful. The Polkadot SDK rustdocs are incredibly useful as a reference, but they offer no guidance and require existing knowledge of the fundamentals of building with Substrate before they become beneficial.

Paradoxically, some see the complexity of building with the Polkadot SDK and the lack of guidance for developers who are new to the ecosystem as advantageous—a feature, not a bug. They believe that because running a Parachain is hard and slots are a limited resource, only the truly dedicated will, or should, succeed—gatekeeping via egalitarian hardship.

But, these barriers to deploying are falling.

“The problem with the slot auction model and it not being agile is it creates high barriers. It creates high barriers into Polkadot … If you have a tinkerer … [someone] who’s just playing around with some technology … [tinkerers] don’t want to be bothered about raising tokens or marketing or finding other people … [they] just want to deploy some code and see if people use it … by forcing them into this model I believe we lose a lot of potential collaborators” (Dr Gavin Wood - Keynote: A New Perspective on Polkadot - Polkadot Decoded 2023)

If we want tinkerers to build on Polkadot, it’s not enough to simplify deployment; we must also improve our developer experience, and this starts with education.

1.2 Details

Accelerate Polkadot is an educational organisation specialising in creating in-depth technical content packages for developers within the Polkadot ecosystem. The packages are goal-orientated; by the end of each package, developers will have built a functional application.

Goal Statement

Our aim is to be the de facto answer whenever a developer asks, “How do I build X with Polkadot?”

1.2.1 Content Package Structure

Each educational content package will be composed of several elements:

  1. Application code: The codebase for the application developers will create while following a guide.
  2. How-to guide (written): An in-depth guide that walks the developer through the practical steps required to build the application.
  3. How-to guide (video): An in-depth pre-recorded video guide based on the written guide. (We must present the same content in different mediums to account for different learning modalities).
  4. Self-guided workshop: An interactive workshop that developers can complete at their own pace. In these workshops, developers will complete a series of coding exercises culminating in creating the final application code. (The workshops have a dual purpose. They support developers who prefer Kinesthetic learning (learning by “doing”), and for developers who have already followed a how-to guide, the exercises can help reinforce their knowledge and improve their retention via spaced repetition)
  5. Guided workshop (video): Pre-recorded video walking developers through completing the workshop. Similar to #3, this will help support visual/audio learners.
  6. Guided workshop coaching materials: Written resources (organiser’s manual, coaching manual/playbook) for community members who want to present the workshop in-person or online at hackathons, meetups, conferences, etc.
  7. Short explainer videos: A minimum of five short videos, each of which will explain a single concept addressed in the guide.

1.2.2 Where We Will Publish

Polkadot does not have a unified documentation location (see 1.3.1 Fragmentation of Documentation) However, we would like to publish on the main Polkadot site under a subdomain such as guides.polkadot.network.

Videos will be published to the existing Polkadot YouTube account. We will stream live to the PolkadotDevs Twitch and Twitter, as well as the Polkadot YouTube and LinkedIn. Recordings of the streams will be published to the Polkadot YouTube account.

Social media content will be posted to the relevant accounts, Polkadot, PolkadotDevs, ink_lang, etc. Code repos will be under the substrate-developer-hub organisation on GitHub.

Wherever possible, we want to publish on existing platforms and channels.

1.2.3 Our First Content Package

During the development of the first content package, we will consult the community about what we will build as the second package. Some of the potential topics could be an NFT marketplace, an auction site, a DEX, an airdrop platform, an escrow system, an automated market maker, etc.

This will be the model going forward; while one package is in production, we will publicly plan the next.

1.2.3.1 The Initial Project

The goal of the first content package will be to build the team management and rewards system for a game, Cores & Conquests.

Players will be able to create guilds, which other players can then petition to join. Guild members will be able to participate in guild governance via voting. This governance will oversee all aspects of the guild, including the admission and expulsion of members, which adventures to undertake, and how to distribute the loot. We will gamify the development of a DAO.

Not only will this project demonstrate much of the Polkadot SDK’s core functionality, but it will also enable us to introduce developers to concepts such as decentralized decision-making/DAOs, Sybil resistance, staking, slashing, and voting systems (quorum voting, permissioned relative majority, quadratic voting, conviction voting, holographic consensus, liquid democracy, etc.) within a familiar context.

The project will be broken down into three applications.

1.2.3.2 The Governance Chain

We will create a governance chain (Bloc) containing the membership management and voting functionality to demonstrate how applications can be composed of multiple specialised chains.

Bloc will be built in Rust with Substrate and FRAME (using the latest release of the Polkadot SDK.)

1.2.3.3 The dApp

The Cores & Conquests dApp will provide the user interface. It will contain minimal business logic and instead defer to Bloc for most of its functionality.

Cores & Conquests will be built in TypeScript using React and Polkadot JS (We may potentially use the Polkadot API, if PAPI is deemed production-ready before development of Cores & Conquests begins. If PAPI becomes the standard for dApps after publication then refactoring the guide to use PAPI would be a perfect candidate for a tip. See section 1.4.1.2).

1.2.3.4 The Sibling Chain - Supplemental

To demonstrate the interoperability of chains via XCMP, we will create a second chain with minimal functionality. This chain will receive an extrinsic from Bloc whenever a new member is approved and emit an appropriate event.

This section of the project will be included towards the end of the guide as a supplemental activity. It is purposefully less complete than the other sections; it aims to spark interest and direct developers to related content. We will provide developers with practical ideas (and additional resources) that they could develop to continue expanding their knowledge, such as minting NFTs for new members on Asset Hub, storing the guild’s crest in IPFS with Crust, or registering a DID and claiming your guild’s web3name with Kilt.

1.2.4 The Platform and Tooling

When considering where and how we will publish our content packages, we will adhere to the following guidelines:

  1. Do not reinvent the wheel
    We want to use open-source or existing platforms wherever possible.
  2. Contribute upstream
    If we make patches or improvements to any of the tools we use, such as Zombienet or the OpenZeppelin Runtimes, we should submit them upstream so the whole ecosystem benefits.
  3. Go where developers are already
    If an audience already exists on a platform, then that is where we should publish. For example, we will work with Distractive to ensure that all videos and live streams are published on the Polkadot YouTube account.
  4. Lower barriers to contribution
    We want the community to contribute, meaning everything must be open-source and use standard technologies.

1.2.4.1 The Platform (Website)

The website will be built using a framework such as Docusaurus, Markdoc, Nextra (Next.JS), or similar. Our requirements are that it is open-source, can be self-hosted, is under active development, and is easily extensible. We want to limit the amount of bespoke development for the platform MVP. However, we have identified some features that will significantly impact the developer experience and that we would like to include within the MVP.

1.2.4.1.1 Code References

Code is often copied and pasted into the article body when authoring tutorials or guides. However, including code in this way can introduce errors and is difficult to test. To avoid this, we will separate the code from the copy.

The final code will be contained within a separate Git repository, with automated testing, code coverage, etc. We can then include it within the guide by referencing the code’s location within its repository and having it imported at build time.

1.2.4.1.2 Showcasing Guide’s Health

The Polkadot SDK changes rapidly; historically, this has made it difficult for documentation to keep pace. This has led to outdated, inaccurate, and often broken tutorials containing code and commands that no longer run. Across the ecosystem, developers’ trust in documentation has eroded because of this negative experience.

We will rebuild this trust over time by ensuring that backwards-incompatible changes are detected early and guides are updated frequently. But in the meantime, we will demonstrate that a guide is up-to-date by prominently displaying its “health” on the platform.

When a developer is assessing the health of an open-source library, there are certain things they tend to look for. When was the last commit? Are there lots of open and unaddressed issues? Does it have many stale PRs? How many contributors does it have? Are its dependencies up-to-date? Does it have tests, and are they passing? How many downloads has it had recently?

Much of this can be gleaned by looking at the projects’ GitHub, and many projects will attempt to summarise their current state by using badges.

Guide content will be publicly available on GitHub, so developers can view it there and make the same assessment. But, like the badges, we will summarise a guide’s current health by displaying its report card.

This report card will include the versions of Polkadot SDK and other frameworks that the guide is tested with, alongside the language version. It will also display essential information from GitHub, such as when the guide was first published and last updated, its number of stars, how many people have contributed to it, and how many open issues currently reference this guide.

1.2.5 Defining Success

Collecting the right data and metrics will be crucial to measuring the success of each piece of content. This will enable us to make data-driven decisions about what to work on next and demonstrate the project’s effectiveness to the community.

We will collect these metrics from multiple sources, including our platform, GitHub, YouTube, streaming destinations, and social media. Some of the data we will collect from these sources will include: pageviews, unique visitors, subscribers, average view duration, stars, forks, pull requests, open and closed issues, clones, and referrals.

We will aggregate the data, remove all personally identifiable information, and publish it in the following ways:

  1. Via a publicly available analytics dashboard.
  2. As a public report one month and six months after the publication of each content package.
  3. Included with each general spending proposal made to the treasury.

1.2.6 Our Core Fundamentals

  1. Goal-oriented: By the end of each guide, developers will have built a small but practical application. Code must be within a real-world context to aid comprehension and retention of what is learnt; metasyntactic variables like foo and bar are not allowed.
  2. Code-first: The codebase forms the foundation of each guide, and as such, it must be accurate and conform to current best practices. The code should be production-ready as far as possible; any deviations from this must be clearly labelled and explained.
  3. Maintainable: Outdated, inaccurate, or broken documentation can be worse than having no documentation. The code contained within guides must have automated tests that run periodically to alert maintainers of breaking changes.
  4. Evidence-based education: We practice evidence-based teaching in everything we do. We understand the unique needs of learners and the importance of addressing multiple learning modalities. We are committed to helping every developer achieve their maximum learning potential.

1.2.7 Learning in Public

“If you’re tired of creating one-off things, start building a persistent knowledge base that grows over time. Open Source your Knowledge! At every step of the way: Document what you did and the problems you solved.” (Shawn Wang - Learn In Public)

Our team is a proponent of Learning in Public. It is an invaluable opportunity for us to be teachers and students. Building in the open ensures we are accountable and the community can provide feedback early and often.

As part of Accelerate Polkadot’s commitment to learning and building in public, we will:

  1. Release all content under a permissive/copyleft license.
  2. Frequently live stream while working on application code.
  3. Live stream rehearsals for video content (guides and workshops).
  4. Use public Git repositories for all code, including work-in-progress code as well as completed releases.
  5. Maintain a public issue/ticket tracker for each package.
  6. As far as possible, seek feedback and conduct all discussions about future content packages, marketing strategies, content collaborations, and so on, publicly via GitHub discussions, the Polkadot forum, or similar.
  7. Publish blueprint/foundation materials (e.g. scripts and storyboards for workshop videos).

1.2.8 Marketing Collaborations

Some of the current Polkadot developer content struggles to attract viewers. Videos languish for weeks, with often only a few hundred views.

Producing content at a higher standard that is accurate, up-to-date, well-maintained, and addresses a range of learning styles will help us reach a larger audience. However, we cannot dismiss the importance of raising awareness among developers.

We are focused on creating highly technical, in-depth educational content. We want to make sure that when developers come to Polkadot, they have a best-in-class experience, but we will leave the amplification of what we do to the experts in the marketing teams.

“This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together.” (Doug McIlroy - Head of the Bell Labs Computing Sciences Research Center)

Accelerate Polkadot will work with marketing and growth organisations within the ecosystem—such as Distractive—to develop a strategy and communication plan for the launch of each content package.

1.3 Ecosystem Fit

The Polkadot ecosystem contains various educational resources at differing levels of quality.

Accelerate Polkadot does not seek to replace the existing educational content; instead, we have identified a type of documentation currently missing within our ecosystem.

“There is a secret that needs to be understood in order to write good software documentation: there isn’t one thing called documentation, there are four.” (David Laing - The Grand Unified Theory of Documentation)

Good documentation requires four types of content, each serving the unique needs of developers during different phases of their interaction with the software.

See the map of documentation needs diagram.

While three of the quadrants have obvious examples: Tutorials (PBA, Polkadot Education Initiative, Polkadot Study), Explanation (Polkadot Whitepaper, Polkadot Wiki, PBA), and Reference (rustdocs), How-To Guides are currently grossly overlooked.

1.3.1 How Are We Different From Other Proposals?

We are pleased to see other Decentralized Futures proposals addressing developer education. It is validating to see other teams, such as PBA-X and the Ecosystem DevRel Team, who also recognise the importance of education to the ecosystem. We fully support their proposals.

Each proposal serves a different, but equally important, need of the developers, and we are excited to collaborate with them.

PBA-X’s content falls into the left quadrant of the above graphic. It is learning and understanding-oriented, and its instruction is teacher/mentor-led. Our work exists squarely within the right quadrant. Our content is problem-oriented and aimed at self-directed learners. After a developer completes PBA-X, they could follow one of our guides to see how to apply their new knowledge to real-world use cases, or a developer may follow one of our guides to familiarize themselves with Polkadot and ensure it is a good fit for their needs before paying to attend PBA-X.

We are a Developer Education organisation, not Developer Relations. Our focus is on creating in-depth developer content. As such, we believe there are many collaboration opportunities between the teams. Some examples of those collaborations are:

  • The Ecosystem’s DevRel team plans to document individual key features, and our guides will demonstrate to developers how they can combine many of those features to create practical applications.
  • We can collaborate on Hackathon topics, ensuring we have workshops covering their various use cases. These workshops could be sent to hackathon participants ahead of the event, providing them hands-on experience with the technologies before the hackathon begins.
  • Our guides will show developers how to build using best practices, but we are unlikely to thoroughly explain why they are best practices. Instead, we will direct developers to the Ecosystem DevRel team’s best practices documentation for more information.

DevRel and DevEd traditionally work very closely together, and we hope that will be the case here, too.

1.3.2 Fragmentation of Documentation

It is incredibly common for frameworks and SDKs to have multiple sources of documentation. A search for “learn React” returns thousands of sites. However, in Polkadot, these different education programs should not compete; we all have the same end goal: to grow the Polkadot ecosystem.

Creating a single unified documentation platform that meets each program’s unique needs is likely impossible. However, a shared education portal could increase discoverability and simplify the developer experience.

This portal would organise and classify educational content from different ecosystem programs. Developers could then find all the educational resources they need in one place. (The portal would not host the content itself, but would direct developers to the relevant resource on the selected program’s site). The need for this type of shared gateway for developers has been raised before at a Parachain summit, and many teams expressed an interest in participating.

The development and maintenance of this portal should be shared equally between the different programs so that each program’s interests are fairly represented. We hope that working together on this could lead to increased collaboration between programs and, eventually, the formation of a Polkadot Developer Education Fellowship similar to the Polkadot Technical Fellowship.

The development of this portal is out of the scope of this proposal. It would require a combined proposal from the different education programs. However, we recognise the benefits such a portal would bring, and if the Accelerate Polkadot proposal is accepted, we will immediately begin discussing implementing it with the other programs.

1.3.3 Target Audience

Everything we create is targeted towards developers.

We assume these developers will already have some experience, not necessarily in our ecosystem, but with the relevant programming languages, development environments, tooling, etc.

As the guides are goal-orientated, we also assume that the developers have at least some knowledge of Web3/Blockchain. Again, we will not assume knowledge of Polkadot or Polkadot-specific vernacular, but it would be unlikely for a developer to seek out a guide on “How do I build a DEX?” without at least knowing what a DEX is.

1.3.4 Collaboration

Missing How-To Guides is not a problem unique to the Polkadot SDK. Other ecosystem projects have similar gaps in their documentation. As each of our guides will be focused on creating functional and practical applications, some of our guides will inevitably be done in collaboration with others.

A key aspect of the Polkadot ecosystem is interoperability. If we do not produce guides that demonstrate this, then we are only showing developers the tiniest fraction of what they can build.

1.3.4.1 Potential Collaboration Examples

Using our initial project as the base, some examples of collaborations we could add might be:

  • Recurring payment of guild membership dues via OAK
  • Calculate the result of an adventure/raid with Phala or Integritee
  • Host the dApp frontend on IPFS with Apillon
  • Distribute loot to guild members with InvArch
  • Mint an NFT when a player joins a guild using Unique or Asset Hub
  • Support DIDs for players and guilds with Kilt
  • Store player avatars in IPFS with Crust

1.4 Future Plans

One of our core fundamentals is that everything we do must be maintainable. Educational content can quickly become outdated; therefore, we must ensure that we can secure enough funding going forward to pay for new content packages as well as maintain the existing content.

We intend to use the grant from Decentralized Futures to fund the initial development and creation of our first content packages—as detailed in the milestones section below—this will help us prove the concept, after which we will seek further funding from three sources: the treasury, sponsorships/collaborations, and coaching.

1.4.1 The Treasury

The treasury already funds several education projects, such as Polkadot Blockchain Academy. We plan to seek funding from the treasury in the following ways:

1.4.1.1 General Spending Proposals

We anticipate that general spending proposals will constitute most of our funding. We will submit these proposals every six months, which is roughly the time required to publish two complete content packages.

Each proposal will contain a detailed breakdown of key performance metrics for previously published packages, ensuring that the community has visibility into Accelerate Polkadot’s impact on the ecosystem and can make an informed decision about our continued funding.

1.4.1.2 Tips

As our content library grows, so will our maintenance requirements. Polkadot’s technology changes rapidly, and it is imperative that we proactively maintain the guides to ensure that they do not become inaccurate or broken. We will incentivise the community to aid with this maintenance via tips. Similar to how developers are compensated for fixing bugs or contributing to the Polkadot SDK, we will reward developers for contributing to the guides.

1.4.1.3 Bounties

There may be times when we seek community contributions that exceed the scale typically compensated via tips. For example:

  • The move to a mono-repo. A large-scale change such as this would impact all guides. Requiring extensive modifications to code and copy.
  • Translation of content packages (written copy and videos) to other languages.

This work is essential but should be separate from the general funding proposals for Accelerate Polkadot as it can be sporadic and unpredictable. Or, as is the case for translations, we do not have the skill set to complete it internally, and would need to use a third-party vendor. We think that if we need to employ outside help for a task, we should do so via our ecosystem.

We will submit a bounty proposal for the first wave of translations within our first six months of operating. With the success of the Polkadot Blockchain Academy in South America and the strength of the Polkadot community in this region, we believe the first translation should be in Spanish; however, we will consult with the community before submitting the bounty proposal.

1.4.2 Sponsorships/Collaborations

One of the key value propositions of the Polkadot ecosystem is interoperability, and we imagine that Parachains will be included within content packages frequently to demonstrate this. We would not seek or expect compensation for including a Parachain in this manner.

We would instead limit paid sponsorships and collaborations to the following circumstances:

  1. General sponsorship: We hope that Parachains and other ecosystem organisations will see the benefit better documentation and developer experience bring to the ecosystem as a whole and will choose to sponsor our work directly.
  2. Specific content package requests: We may occasionally be approached to develop content packages covering a specific topic or technology. While better-educated developers benefit the ecosystem as a whole, in instances where they directly benefit a company, we expect them to cover development costs, not the treasury.
  3. Custom modifications: Sometimes, an organisation may wish to customise a workshop or other content to better demonstrate or teach a particular technology. All the content we publish will be open source, so they will be free to do so; however, if they would like us to create a bespoke version for them, that would incur a charge.

1.4.3 Coaching/Workshops

Guided and self-guided workshops, as well as coaching materials, will be available with each content package. However, if someone wishes to have Accelerate Polkadot perform an in-person or otherwise private workshop for their organisation, this would require a fee.

2. The Team

Our founding team has over 30 years of combined experience in programming and 15 years in education. They are accomplished engineers, keynote speakers, mentors, educators, and PBA graduates. They have a wealth of experience in content creation and the development of EdTech platforms.

They were fundamental in developing several fully accredited multilingual LMSs (Learning Management Systems) that millions of students use daily. These platforms have won a large number of awards, including five Bett (British Education and Training Technology) awards, two ERAs (Education Resources Award), three DevPortal awards, an Interactive Media award, an ELTons (English Language Teaching) Award, and a Teachers’ Choice award.

2.1 Future Team Growth

Eventually, we would like to hire additional engineers, developer educators, and editors to allow us to increase the scope and frequency of our content packages. We will also want to hire a dedicated platform and tooling team.

But we do not want to scale up too much. Instead, we aim to keep our team lean and encourage the community to contribute via bounties and tips.

3. Milestones

Phase one of the project will require an estimated 514 work days. This consists of 321 days of task-based work plus 25% for non-task-based items such as participating in public discussion, triaging tickets, meetings, etc., and an additional 30% as a buffer due to the difficulty in accurately estimating such numerous tasks. While it is best practice to include a considerable buffer in these situations, we hope to come in under budget. Any remaining funds will be allocated to the development of content package 3.

This is not 321 days of consecutive work, as many of the tasks can be performed concurrently. If everything runs according to schedule and phase one starts on April 1st 2024, the last deliverable will be completed on December 23rd 2024.

Milestone Area Delivery Date
Company setup/registration Administration 2024-04-05
Platform MVP Tooling 2024-04-25
Application Code Finished Content Package 1 2024-07-04
Written Guide Published Content Package 1 2024-07-20
Self-Guided Workshop Published Content Package 1 2024-08-02
Video Guide Published Content Package 1 2024-08-23
Social Videos Published Content Package 1 2024-08-27
Guided Workshop Published Content Package 1 2024-09-02
Coaching Materials Published Content Package 1 2024-09-11
Application Code Finished Content Package 2 2024-10-14
Written Guide Published Content Package 2 2024-10-30
Self-Guided Workshop Published Content Package 2 2024-11-12
Video Guide Published Content Package 2 2024-12-03
Social Videos Published Content Package 2 2024-12-06
Guided Workshop Published Content Package 2 2024-12-12
Coaching Materials Published Content Package 2 2024-12-23
13 Likes
2

The forum has some pretty strict restrictions on the number of links and images you can include in a post. I recommend viewing the Accelerate Polkadot Proposal doc as it includes a lot more context.

2 Likes
3

I wonder, given the “don’t reinvent it” ethos, if one or more substrate-* modules in testcontainers makes sense in this context?

Would the Desktop App give you a running start for a particular segment of developers (“I just wanna have a RC and PC running. Now.”)?

4

Hey @taqtiqa-mark! I’m one of the developers with Accelerate Polkadot, and I think that’s a great suggestion.

Developer tooling is definitely something we’ll be looking at closely when creating the guides and workshops.

Building a node can take 15 to 60 minutes, and spinning up a chain and syncing with Rococo can take days! Timescales like these could cause developers to lose interest and abandon a workshop without completing it. We’ll be looking at multiple options, including containers, to find a solution that shortens the feedback loop without adding too much setup or complexity for students.

1 Like
5

Is there a place to see who is on the team? I can’t seem to find that in the proposal.

6

Hi @mister_cole!

The founding team will be myself and Aaron (who is also responding in this thread). We are both currently with Parity; I’ve included some more details about us below.

Lauren Lee

LinkedIn

I’m a teacher-turned-software engineer. I’m super passionate about community, education, and empowering developers to learn to code. I’ve found success speaking, streaming, writing/coding demos, tutorials, and workshops. And also thrive in leading teams of educators and developers.

Aaron Bassett

Download CV

Aaron is a Principal Software Engineer with over two decades of experience. His expertise lies in creating engaging use cases and educational content that appeals to a wide range of audiences. Aaron is passionate about knowledge sharing, which is evident in his roles as a keynote speaker, educator, workshop presenter, and mentor. He has a strong presence in the developer community, with significant contributions on GitHub, and numerous conference talks.

Beyond the two of us, to ensure the highest production standard, we will likely require the services of professional designers, illustrators, animators, and video editors. Initially, we’ll contract with freelancers on a per-project basis to meet these needs. However, once we have proven the project’s success and secured sufficient funding and runway, we will look to hire full-time employees for these roles.

6 Likes
7

So this is a primary hub for everything substrate. Following the discussions in the substrate group, folks are facing issues frequently due to outdated tutorials?

Going by the latest commits, I see some core-devs are working on it to update.

But I believe its not actively maintained like it was used to before decentralization? Is there any team working on this?

8

Hey @muddlebee!

This is an entirely separate project in no way connected to the existing substrate.io website. As far as I am aware, there are discussions happening internally to archive and eventually remove docs.substrate.io

Not at all. Our first content package will use the Polkadot SDK (including Substrate) and Polkadot JS, so it is chiefly targeted at Substrate and dApp developers. However, the guides, in general, will not be focused on just one particular technology.

They will use whatever technologies are relevant to reaching their goal and building the application. Sometimes, this will be Substrate; other times, it might be ink! Or it might be an SDK from a Parachain like Kilt, Crust, Phala, etc.

The guides will focus on equipping developers with the knowledge needed to build practical applications in our ecosystem using whichever tools and technologies are needed to complete the task.

2 Likes
9

First time ever that I hear this. Goes like against everything we have done over the years. Maybe you misunderstood something.

Can you give examples of such written guides in the context of Polkadot that you have produced?

3 Likes
10

Hi @bkchr,

Written content wasn’t prioritized in our current roles; however, we have experience creating other educational content with Polkadot—live streams, workshops, conference talks, a PBA module, etc.—and a wealth of experience writing technical content in previous positions.

It is precisely the lack of this sort of content for Polkadot that makes this proposal so important.

11

Could you shed more light on this, it would appear to impact how this proposal may be viewed. Specifically, if it is a step towards making more likely that docs.substrate.io is eliminated.

There was a concern, at the time of the merge of substrate into the Polkadot repo, that Substrate was being subsumed into Polkadot, never to re-emerge. A move to eliminate docs.substrate.io would shed additional light on those claims and counter assurances.

12

Hey @taqtiqa-mark,

This proposal has no relation to or bearing on docs.substrate.io or any other existing documentation site.

You can read more about how we see this proposal fitting with existing documentation in section 1.3, but ultimately, “Accelerate Polkadot does not seek to replace the existing educational content; instead, we have identified a type of documentation currently missing within our ecosystem.”

13

Understood. I asked if you could shed light on the issue you raised. I take it you can’t. That’s fine

14

This proposal is well structured and i do think this is needed. I’m not sure where the engagement with CryptoZombies went, maybe this is something you could pick up as well? we’ve already paid for it. Also, i know there is a big MooC, not. PBA -X but another one, wonder how this fits into the plan

My main point is that the most important thing for Polkadot to grow is to get a product led growth engine going. This is really the only way we can scale and can attract newly formed teams (which BD cannot identify) and product led growth largely is based on clear documentation, gamified documentation that provides an obvious next, small step to take in the ecosystem.

I see your proposal as an important foundation stone in a broader product led growth GTM strategy

2 Likes
15

Thanks for your support, @Nick :blush: I’m glad to hear it aligns with a broader product-led growth GTM strategy. And yes, providing that obvious next step to those trying to learn how to build is exactly our goal.

Re: your question on CryptoZombies - agreed, we love this sort of gamified content and think it’s incredibly important. Some developers really enjoy a gamified learning experience, and it’s crucial Polkadot has educational content for them. We’re happy to engage with CryptoZombies and see if there is a way to collaborate/support them in delivering the workshop.

As for how we fit in with massive open online courses and PBA-X, we’re confident that all of these initiatives are necessary for our ecosystem. We’re super happy they exist and are excited to collaborate with them.

16

I completely agree! This is one of the reasons we’re so focused on ensuring that each guide demonstrates how to build a practical application with real-world use cases. This has an obvious benefit for developers/teams who already know what they want to build; they’ll be able to leverage a guide for their use case to accelerate development.

Additionally, the guides will raise awareness of what is possible with Polkadot. We hope this will motivate developers, stimulate innovation, and attract teams from other ecosystems who may not know Polkadot’s unique capabilities and the benefits they could bring to their products.

Thank you, I really appreciate your support!

I’ve always been inspired by Polkadot’s tech and its potential applications. Hopefully, we can help bring more developers and teams into the ecosystem; it’ll be exciting to see what they create.

17

I’m also curious to see some concrete examples of this new form of guides and documentation.

Producing good documentation is not an easy feat, and having used extensively Substrate/Polkadot docs and specs, I can see that a lot of effort was put into it. The thing is that Polkadot tech is complex, and evolves constantly, which makes it difficult to cover extensively in documentations. In my opinion, tutorials are good as shallow entry points to familiarize a bit the Polkadot notions. But the pressing and useful need is for deep, detailed and comprehensive technical documentation to build real products (that means improving on the existing docs). As an example, to add to the documentation site how the concatenated XCM fragments, blobs or signals work without having to look a the source code.

18

Hey @sodazone! Thank you for the feedback! Hopefully, I can alleviate some of your concerns.

As you said, this proposal is for a new form of documentation—one that we are sure does not yet exist because it is the documentation we wished we had when we started building with Polkadot but couldn’t find.

Without question, this will be a lot of work.

While working at Parity and during our time at PBA (first as students and then as faculty), we have become intimately familiar with the existing documentation and gained a lot of experience developing with Polkadot. We know how complex the technology can be, how rapidly it evolves, and how these factors pose a unique challenge when creating documentation.

We know this is a considerable undertaking, and we are fully aware of the scope of the work ahead of us. We hope it is evident from our proposal that we have not approached this project lightly; we have given much thought to not only what is achievable now—within a realistic timeframe—but also how we can ensure that the guides are properly maintained in the future and keep pace with the latest Polkadot developments.

:100:

I completely agree; our purpose statement says almost the same thing: “An educational organisation which creates goal-oriented, code-first, in-depth guides on building practical applications within the Polkadot ecosystem.”

This proposal has no relationship to or bearing on the existing docs; it will not hinder or impact their continued development in any way. To the contrary, we sincerely hope that the existing docs will continue to improve as developers need different types of documentation.

Some developers like to learn by reading the code, others are more like you and do not want to look at the source code, preferring detailed technical documentation, and some developers are kinesthetic learners who prefer to learn by doing and need more hands-on guides.

Just as we think you should continue to have great documentation supporting your learning, we also think other developers deserve educational resources geared toward their learning styles.

1 Like
19

I support the idea of having hands-on code-first learning activities. These were my same goals when I was maintaining the now outdated Substrate Recipes circa 2020.

4 Likes
20

Thanks, @JoshOrndorff :teacher:t3: I appreciate someone with so much teaching experience and a pedagogical POV supporting this idea. It means a lot to have someone with your experience validate both the problem statement as well as our idea/solution.

1 Like