Summary
This post discusses potential goals that Polkadot Governance can set for itself. They have been gathered from discussions in recent days on the forum and other channels. I want to invite you to check them if they are sensible and complete and suggest any changes you think are meaningful.
Goals
Polkadot ecosystem success will not happen automatically and is not even guaranteed. We need to work for it. Polkadot stakeholders can influence the process by shaping governance. As I have laid out in this potential Polkadot Governance Framework, shared goals are at the beginning of this process.
Goals represent the convergence of stakeholder intentions in Polkadot Governance. They tell us where to direct our attention and resources and on which topics we should formulate initiatives and programs. Goals tell us where we lack something or where we need to get stronger or can strategically grow.
From recent discussions, I have gathered these shared goals:
- Increase coretime demand
- Increase the number of chains/apps created
- Increase developer adoption
- Increase user adoption
- Bootstrap Collectives
- Bootstrap Voter Committees
Hierarchy of Goals
We can assume this chain of value flow:
Coretime Demand ← Chains/Apps ← Developers
In other words: If we get a lot of prospective developers, they will innovate on a lot of apps and chains and this will eventually result in a lot of coretime demand.
Attracting users scales with the availability of meaningful apps.
Bootstrapping Collectives and Voter Committees are short-term goals to increase the velocity of governance development, which in turn helps to properly position the Polkadot ecosystem.
I will now briefly discuss those goals and then invite you to share your thoughts.
Increase Coretime Demand
This is seen as an essential goal to consider the Polkadot Relay Chain a success. It is easy to measure, but can’t be directly influenced. Coretime demand is created from parachains, and other future constructs that consume coretime to operate applications. Incentiving activities that intend to directly influence this goal tend to be long shots, e.g. subsidizing the development of parachains.
Increase the number of chains/apps being created
Apps built on chains and other future constructs are the consumers of coretime. The more meaningful apps we have in the ecosystem, the more user demand we can expect. Additionally, the availability of meaningful apps can lead to additional network effects where apps can make use of each other, which increases the utility of the ecosystem for new incoming developers. It is fairly easy to measure but is also only indirectly influenced. Activities that influence the development of new apps and chains are closely correlated with the next point.
Increase Developer Adoption
and its twin “Improve Developer Experience”. This goal is about making it attractive and easy for developers to join the ecosystem. It is not easy to measure but can be fairly directly influenced. A lot of suggestions have been posted in this thread and span a range of topics, such as Substrate, XCM, ink!, APIs, tooling, explorers, etc… Activities that influence this goal are availability of documentation, reduction of technical debt, generalized and simple APIs, accessibility of primitives in the ecosystem, etc…
Increase User Adoption
and its twin “Improve User Experience. Not as much discussed as the previous goal, but generally be considered of crypto overall: UX. Acceptably easy to measure (maybe not easy to aggregate), acceptably easy to influence, but hard to nail. Requires concerted effort by developers and a strong focus on UX and product-market-fit, as well as products that actually make sense and are demanded by users. This goal is also worthwhile because every developer joining the ecosystem joins it initially as a user. Activities that influence this goal mostly lie in the hands of the teams that develop actual apps. So Governance has only mediated influence over the realization of this goal. Activities that influence this goal are in the area of tooling and services, UX awareness, and funding user-facing projects.
Bootstrapping Collectives
On-chain groups of ecosystem agents that unite under a charter and possibly a system of ranks and a payroll. Collectives are advanced enough on the technical side to be partially rolled out already on the Collectives system chain. But not many people are aware of them yet, so we should work to actively disseminate the information.
This is easy to measure and should be acceptably easy to influence, but is hard to guarantee. Collectives form best around already-established groups that want to take their relationship to the next level. Forming them out of nothing could be a recipe for painful failure.
Activities that influence this goal are proper dissemination of information and possibly converging towards a proper incentive scheme.
Bootstrapping Voter Committees
Voter Committees are similar to political factions in traditional politics. They are groups of voters that vote together, based on shared policies. Bringing transparency into this process by inviting voter committees to step forward and out themselves, give themselves a profile and platform, and appoint delegates to negotiate with other parties would be helpful in increasing the velocity of the legislative branch and creating better consensus-building mechanisms.
Activities that influence this goal are similar to those of bootstrapping Collectives. Voter Committees that willingly play by additional rules (e.g. being public, having appointed delegates, etc…) could be subsidized by the Treasury if it is seen as beneficial to the overall governance process.
What do you think?
Did we capture all relevant goals that Governance could work towards? Should goals be structured differently? Is something missing?
Agreeing on a set of goals will help us to formulate initiatives and programs and allocate budgets correspondingly.