Developer Experience must be our #1 Priority

Governance
47

I want to provide a summary of what I see has been discussed so far. It’s hard to capture all aspects of the discussion in a succinct way, but I want to provide a starting point here. I think some of those points eventually should lead to bounties to allow developers in the eco to provide solutions.

End-to-end thinking is missing

Many Parity folks in this discussion were mostly concerned about Substrate developers (to the extent that their language only revolves around Substrate). On the other end of the spectrum, we had dapp developers who expressed not being seen and recognized by Parity and even parachain teams.

This observation matches with the original mindset of (in my words) “Parity builds Polkadot, Parachains build businesses”, but has in effect lead to these problems:

  • Duplication of effort: parachain teams have to re-implement the same QA processes, middleware, frontend solutions
  • Non-integrated solutions: While logically a separation of concerns should separate dapp development from parachains, there are several UX issues originating from this separation.
    • Users have to manage several accounts, while they are based on the same seed and could be represented as the same account, at least user-facing
    • Users have to manage several fee tokens, which are hard to acquire

A change of mindset can be noted. While originally it was thought that “Parity builds Polkadot, Parachains build businesses”, with the paradigm shift to the “ubiquitous computer” and the conception of new work types and the actor model for Polkadot, it no longer makes sense to treat everything as its own. Functionality in Polkadot is interdependent and we need to adopt an integrated view. This means thinking end-to-end, starting with the end-user experience in mind and building layers that actually work towards catering to users.

Proposed Solutions

  • provide more AI-supported documentation over the full Polkadot development space
  • more explicitly define conventions of how things should be done (e.g. using the xtoken standard in such and such manner) to reduce heterogeneity where it is not useful
  • improve tooling over the whole development process
  • parachains should start to accept DOT/KSM as gas token. This can be implemented in addition other native tokens. It makes sense economically too, since parachains will need DOT to pay for coretime on Polkadot.
  • We might want to agree to present a unified account ID to the user to reduce confusion
  • special hackathons that focus on integrating 2 or more parachain features within a single app would foster innovation and highlight integration issues that are still present when building apps on Polkadot.
  • provide standardized frameworks that connect to multiple chains easily and let users pick and use all available Polkadot wallets
  • Provide middleware that abstracts away account management for the user and/or requires them to sign fewer transactions, or enable use cases that force users to seemingly only create an account after they have used a product for a certain time (while it might already have existed and automatically signed transactions in the user client)

Reduce the Complexity of Building in Polkadot

Some issues in this area are already being addressed, such as

  • the Substrate codebase changing too frequently → addressed by stable long-term support versions of Polkadot
  • bootstrapping collator networks is a lot of effort → addressed by Tanssi
  • documentation

Proposed solutions

  • Direct devs to first build smart contracts before they build parachains. If they don’t know if they should build a smart contract or a parachain, default to suggest smart contracts (since they obviously haven’t hit a real barrier yet and are still only conceptualizing)
  • Improve Developer onboarding and support
    • visible and available videos, course, resources, docs
    • accelerator DAO
    • Key accounts from Parity, even for builders/teams that are only onboarding
  • reduce the complexity of XCM/interop, such that chains opening channels becomes far easier. The theoretical limit here is users opening channels permissionlessly and transferring assets. This is often not the actual goal, but if the system becomes this easy to use, a lot is achieved.
  • make it easy to implement actual chain-to-chain APIs, such that it becomes as simple as doing REST calls.

Substrate

Raised issues:

Proposed solutions:

XCM

@albertov19 pointed out that weight calculation is hard and XCM construction is complex. Suggested solutions include to request the destination chain to calculate the weight via a runtime API call and to create wrappers around XCM that make construction easier.

10 Likes