Polkadot Summit 24' - Boosting the Developer Experience

Ecosystem
1

Boosting the Developer Experience

Hi all, please see below a write up from one of the Polkadot Summit sessions that was held in Bangkok in 2024.
You can use the polkadot-summit tag to see all the other posts, and navigate to the summary post for a recap of the event.

11th March 2024 / POLKADOT SUMMIT ASIA

Host: Joshua Cheong | Parity
TG/X Handle: [@joshuacheong]
Element: @joshua:parity.io

1200Ă—1600 366 KB

Joshua Cheong - Hosting a workshop on Developer Experience the Summit

Summary of the session

The session focused on evaluating and improving the developer experience (DevX) on Polkadot, drawing insights from a survey conducted in early 2023 involving 35 respondents with 4-5 years of experience in Rust.

The survey aimed to understand the duration of key technical development processes within the Polkadot ecosystem. It covered various development stages, from ideation and white paper to MVP testing and launching on Polkadot or Kusama.

The presentation also highlighted areas for improvement based on feedback from 52 respondents, emphasizing the need for better documentation, developer tools, community support, educational resources, and feedback mechanisms. The workshop then branched into 3 key areas for discussion:

1. Bootstrapping issues for building in Polkadot

2. Ongoing development experience issues with Polkadot SDK (Substrate)

3. Using Polkadot - End user experience issues

Notes & Key questions asked

Feedback from Developers: The survey identified the longest process steps as “1-click deployment runtime templates,” “Openzepplin Tanssi eg.,” and “In-code documentation (rustdocs).” The introduction of a new permissionless testnet (Paseo) and coretime purchase options are responses to streamline processes.

Key Improvement Areas:

  • Comprehensive and Accessible Documentation: Including detailed guides, use case examples, and troubleshooting tips.
  • Streamlined Developer Tools and Infrastructure: Development of efficient tools and robust infrastructure for deployment and testing.
  • Active Developer Community and Support: Fostering a vibrant developer community with dedicated communication channels and technical support.
  • Educational Initiatives and Resources: Offering tutorials, workshops, and webinars for various skill levels.
  • Funding and Feedback Mechanisms: Creating incentives for development and establishing channels for collecting and acting on feedback.

Group Discussions:

These discussions aimed at dissecting the developer experience further, encouraging participants to explore ideal states for development, the division of responsibilities, key next steps, and success metrics for improvement initiatives.

Bootstrapping issues for building in Polkadot

  • Depending on the project, one should pursue different avenues of funding. Source of funding discussed:
    * Decentralized Futures Program
    * Polkadot Treasury
    * VC funding
    • Crowdloan was nice, now without coretime, there is no crowdloan.
    • Some projects that have gone through Treasury have had a rocky experience. Some developer teams are afraid of going to Treasury because they want to avoid politics. Treasury was also noted as good for bootstrapping but not sustainble.
    • VC funding is not for all use cases not always necessarily aligned with the Web3 ethos as there is a centralized entity that has a major stake in a decentralized protocol.
    • DF is closed and not transparent, and overall the feedback from teams has been that DF has been very slow at funding.
    • Overall, Polkadot needs a better on-ramp to quickly get developers with good ideas funded.

Ongoing development experience issues with Polkadot SDK (Substrate)

  • Tech release management appears to be the biggest painpoint on the parachain lifecycle. More was asked to prompt for other painpoints to raise about DevX but this was the only thing everyone had their emotions over repeatedly. Some low hanging fruit identified such as:
    • explaining the definition of sections in the release notes (eg. what you mean by node etc.)
    • ensuring any non-compatible breaking changes (changing the API or interfaces or removing params) must come with a step-by-step migration guide in rust docs directly along with the necessary testing steps and linked to the release notes.
    • Lastly, a decision must be made to have a reasonable LTS that anything which requires a migration guide must not be pushed if it is not an LTS version. (Of course exceptions include bug fixing)

Using Polkadot - End user experience issues

  • Many ideas were discussed. One in particular stood out to us as the idea to have 1 common universal payment token across the relay chain and any parachain. This can potentially be achieved by making $DOT a sufficient asset.
  • Many other ideas covered that are captured in these photos:

900Ă—1086 187 KB

898Ă—1010 1.11 MB

Key Takeaways & next steps

  • The session emphasized the importance of enhancing the Developer Experience (DevX) on Polkadot to facilitate smoother development, deployment, and support for projects built on the ecosystem.

  • Future Actions: Implementing improvements based on the feedback categories identified, with a particular focus on creating detailed and accessible documentation, improving the developer toolset, fostering a supportive community, ramping up educational efforts, and enhancing mechanisms for incentivizing development and collecting feedback.

  • Community Engagement: Encouraging community-led initiatives and discussions, like those started during the group discussions, to continually refine and improve the developer experience on Polkadot. This involves active participation in platforms like the Polkadot Alpha program and improvement requests.

  • Evaluation and Follow-up: Establishing metrics to measure the success of the initiatives implemented and ensuring an ongoing dialogue with the developer community for continuous improvement.

These summary notes serve as a starting point for understanding and engaging with the improvements in the developer experience within the Polkadot ecosystem.

4 Likes
2

What are other ecosystems doing? I would assume they rely a lot on VCs?

Yeah, we should really push the ecosystem for doing this. Makes it much easier to interact with the parachains. We should make this some sort of “standard”. Parachains can not be forced, but it would be nice if they do this.

Generally the question is what do people understand by LTS? They can continue running their parachain without it breaking? Or do they only want to have bug fixes?

3

The easy way is to improve the current transaction-payment pallet to include such feature and by default every parachain will have it. and I raised this issue almost 2 years ago Improved transaction payment pallet · Issue #273 · paritytech/polkadot-sdk · GitHub

2 Likes
4

If multiple teams already have implemented it, it would be a good idea for one of them to upstream their solution. Then, as you said, everyone can benefit from this quite easily.

5

Small note that crowdloans as a possibility are not going anywhere, the actual implementation provided by the Polkadot is going away. An existing parachain or smart contract can fairly easily re-introduce a similar mechanism, now even with more flexibility thanks to coretime. @shawntabrizi elaborates on this in his recent interview here.

I am seeing a few great DF proposals from the ecosystem raised to improve this, such as this and this. Yet, as core engineers at Parity, we are also working on much better low level rust-docs that cover fundamental topics, alongside key guides that cover important user journeys. We hope that these baseline documents can act as the source of truth for more ecosystem teams to reliably build tutorials without going out of date. You can learn more about this effort here. I hope some changes are already present, for example most FRMAE macros now have much better api docs that showcase all possible syntax variations. I will provide a more detailed update on this in a separate thread soon.

I am usually positively surprised when I see all the great people actively maintaining https://substrate.stackexchange.com/ and, in case anyone is not using it already, I want to pose it as the first community step. Also raising the fact that the next community moderator election for our SE is in a few weeks. :eyes:

For more technical matters, We have pinned two issues to the polkadot-sdk tracker list, where developers can link and upvote the issues that they think deserves more attention. Much more can be done regarding feedback though, no doubt in that. This is a simple shoestring approach for the short term.

3 Likes
6

One recurring important thing is that we can make all these cool changes at the protocol level, like generalizing the pallet transaction payment so that multiple assets are supported, etc. But if we don’t update our tooling, like the Polkadot-JS SDK, so that you can easily pay tx fees in other tokens, these changes won’t have the expected impact/adoption.

To summarize, any change that we propose/implement needs to be accompanied by the right documentation, tooling, and demos to impact the ecosystem.

I feel that a lot of what is happening at Polkadot is that many things are done at a protocol/runtime level, with no continuation to the other verticals I mentioned. Therefore, the impact is extremely limited.

5 Likes