#10: A Short-Term Roadmap

In the minds of the community, I hope that there is very little doubt now that we ourselves have both the capacity and the responsibility to realize NoM's full potential.

However, if I am being honest, our efforts right now feel very amateurish.

My belief is that the best results are achieved through open, iterative, and collaborative processes. This past week, I thought hard about how we could transform our community into a machine of efficient delivery while remaining committed to these ideals.

Community members are also worried that we won't have made enough progress by the next Bitcoin halving. Governments around the world continue to advance their plans of financial control.

At the current pace and level of delivery, I too am unsure how much of our road-map that we can achieve by the time we need it. Whether out of necessity, idealism, or inability, our founding developers have not provided the leadership that most of the community desires. For a truly decentralized community, this is not a problem. But we must fill this gap urgently.

IMHO, there are three important issues that we must address.

First, we need development processes that enable new contributors to quickly become productive and let the best community members available deliver the work.

Second, we need confidence in our deliverables. The distribution of community funds requires accountability and community confidence.

Third, we need to both increase existing developer productivity and to find ways to strategically bring in new contributors. We cannot rely on volatile price action alone to attract the talent we need.

Software Delivery Life Cycle

All software development starts with an idea. But ideas are only as good as the quality of their execution.

Most of the on-chain development that the community has done so far has been restricted in scope to specific embedded contracts. As we continue our road-map, items such as embedded governance, dynamic plasma, networking refactors, sentinels, narwhal/tusk are much deeper in scope with bigger consequences for failure.

Our community is no stranger to dealing with setbacks, but if we are asking people to invest their time and money into the project, we cannot afford to have a cavalier attitude.

I won't fault developers for delivering in good faith what they believe the community will accept. We each have our own personal ideas of minimum standards. And assuming that NoM will be successful, as an AZ incentivized developer myself, keeping standards as low as possible as long as possible actually benefits me personally.

But we can't assume that NoM will be successful, so we have to teach the community what good software delivery looks like. We have to show what a rigorous testing plan looks like when needed. We have to show what good developer and community documentation looks like. I'm not sure how we can attract and retain the best talent, unless we show that we are a serious community. We must strive for excellence.

We will achieve this through an open, iterative, and collaborative process. A good milestone for payout is when enough work has been done to enable additional people to contribute and compete.

Planning and Design

I first propose that for all major work, we have a dedicated time-boxed planning and design discussion phase.

Poor design which gets implemented results in technical debt that future AZ proposals will need to pay to fix. The right conversations upfront mean that all considerations and approaches can be represented, so that the community can make an informed choice on the trade-offs being made.

During this phase, we want as much community input as possible.

To incentivize this, I propose that we earmark funds and use a pillar vote to distribute those funds to discussion participants. For example, we could give each pillar 3 votes on who made the best design discussion contributions. We can set some rules around quorums to prevent abuse. Really what we are striving for is a decentralized oracle incentivized to fairly judge relative contributions.

By incentivizing design and decoupling it from implementation, we discourage the hoarding of ideas and insights, and instead encourage transparency and collaborative discussion.

This process also allows new community members to quickly contribute while learning about the project and gauging their level of commitment. There have been some comments on enabling the broader non-developer community to contribute, and this phase presents such an opportunity.

The goal of this phase should be determining the high level approaches which are possible, their milestones, and how it can be broken up into separate implementation phases.

Implementation

Once the planning and design discussion has been exhausted or the timebox has ended, it is likely that multiple software components have been identified as affected or needing to be built.

At this point in time, individuals and teams can submit their proposals for delivering the work for specific or multiple identified components. Proposals should specify which approach as discussed during the planning/design phase they wish to implement, their requested funding, and an estimated time-frame of delivery.

We will then facilitate the pillars selecting, negotiating, or rejecting these proposals. Contributors should have assurance that if they deliver the work, that they will be paid accordingly. The community should not feel hostage to delivered work. In terms of negotiation, we could for example, set different payment amounts based on speed of delivery. The faster the better.

In the case of rejection, or lack of implementation proposals: having a backlog of planned/designed work is a good problem to have especially as we welcome new contributors.

Documentation, Socialization, Marketing

It many cases, it may be beneficial or even necessary to have dedicated documentation and socialization proposals which cover things such as developer documentation, community tutorials and narratives. Efficiency means allowing specialization, and often times the best developers are not the best technical writers and vice versa.

If the work has compelling narratives around it, the artifacts of documentation and socialization can serve as the content for marketing initiatives.

These proposals can be done after the delivery or possibly even in parallel.

Embedded Governance

I will use the embedded governance work to test trial and refine this process. I'm asking the community to earmark 5k ZNN and 50k QSR for the planning/design phase of an embedded governance contract. The embedded governance contract will be relatively consequential; we want to get it right, so I am comfortable earmarking that amount. In the future, we will need a process to set planning/design discussion phase amounts.

I will begin this tomorrow, and facilitate the end-to-end delivery of embedded governance. I am committed to finding the best contributors possible to deliver this work, whether it be me or someone else. We can advertise this as well on social media/Twitter.

I suggest a two week time-box for planning and design, ending July 4th.

After that we will then proceed with implementation proposals for embedded governance and begin planning/design for Dynamic Plasma, Sentinels, etc. If the process is successful, I believe that facilitation should be incentivized. Long term I believe that we can create a free market of facilitation. Perhaps someone else in the community can facilitate the next major piece of work.

Don't Trust. Verify Value

I find it strange that we as a community are valuing things based on time spent or number of people involved. Rewarding based off these factors creates perverse incentives. As mentioned earlier, the faster someone is able to deliver the better. Effort also cannot be verified. This approach is completely antithetical to how permissionless decentralized systems work.

This year at my salaried job, I'll make over 300k USD, not including things such as benefits and other perks. Because of my work on NoM, my career advancement packet is a lot thinner than it could be. A lot of that time has just been on reading research papers and learning about our network and other networks. There has been real opportunity cost to working on NoM, and if we start paying out based on time spent, as a rational actor I will submit some bills shortly.

My point is not about my personal situation, but that you have no way to verify these claims. And even if you could, so what? We must incentivize value, not effort.

However I also recognize that the community has not had a good way to judge value, as most work has not been tangible so far until it has already been deployed to production, so bad proxies are being used instead.

We need make it easier for developers to demonstrate tangible value in an iterative fashion. I propose that as a community we require all major network upgrades to be accompanied by a dedicated public testnet. This creates a verifiable interface for developers to demonstrate progress. By creating tight feedback loops, developers productivity will also increase.

In addition, as some of my HyperCore One teammates have lamented, "it works on my machine" is not good enough. We have learned over the past few weeks that development environments cannot adequately capture real world conditions, much less adversarial ones.

In order for requirements for testnets to be realistic however, we need to lower the burden of creating and operating them. In my next post, I will go over my plan for a suite of off-chain tooling to enable this. It will undergo a similar open design process as above, but geared towards developers and likely more opinionated in terms of tech stack for off-chain interoperability purposes.

This tooling will also be multi-purpose in the future. In addition to testing, the ability to dynamically create and configure new networks will highly relevant to layer 2s and extension chains.

ZONUM Revival

I have seen some ideas floating around on how to get more eyes on our community. I have seen some of them done within other communities with varying degrees of success. It is hard to escape the realm of "gimmick".

I saw a tweet from Sultan that made me think:

The tooling suite I mentioned above can also form the foundation for the recreation of a ZTS tipping service, a ZONUM revival. I believe that a strong tipping culture can drive high levels of engagement within our community, and serve as a very strong outbound marketing tool for new contributors.

There are some possible issues with Twitter due to its API pricing and possible violations of Terms of Service, so we'll have to be smart about how we do it. I think there is also a relevant audience on Nostr as well.

I will pursue this avenue of outbound engagement and define this work once some of the foundational tooling is in place.

Long Term Roadmap

To summarize, before we can effectively tackle our long term roadmap I believe we need 3 things:

1. Processes which incentivize collaboration to achieve the best end result
2. Better ways for developers to receive feedback and for the community to verify work
3. Engaging ways to acquire new contributors

Once we have made progress here, I will be more confident to start breaking down our advanced technical items into a tangible roadmap.