Regular Scheduling For Our Tezos Proposals
The teams at Nomadic Labs, Metastate, Marigold, and DaiLambda have participated in a number of joint protocol proposals for Tezos; some of us have been working on the code since the original launch of the Tezos network, and have been involved with updates from Athens through the recent Delphi proposal. Over time, we have gained more and more experience and have learned what practices seem to work best for updates to the Tezos ecosystem.
Up until recently, we have generally focused on releasing proposals when a particular pre-determined set of features have become stable. As the community has matured, and as we have gained experience, we have developed the belief that it is better to release proposals on a regularly scheduled basis instead.
The rest of this blog post describes our reasoning.
In software development, teams are often tempted to release a new version of their code only after a particular set of features is complete. The problem with this approach is that it often leads to releases occurring at longer and longer intervals.
The syndrome tends to work this way: a particular feature is on the must-have list for a release, but is delayed. A developer of another feature worries that because the gap between releases has increased, it is important that their feature be incorporated before the next release or it may not see the light of day for some time. The work to incorporate this change then delays the release further.
Then, other developers notice that releases are happening at longer and longer intervals, and they in turn become more and more worried that if they don’t get their features into the next release, it might be a very long time before users see it.
Soon, a vicious cycle is in progress where releases happen further and further apart, first being delayed by months, and then by years.
One remedy that many projects have found for this problem is straightforward: release code regularly, at scheduled intervals rather than when particular features are complete.
The reason this works is also straightforward. If trains leave a station every ten minutes, few people will be worried about missing a train; there will always be another a few minutes later. However, if trains leave without a fixed schedule and at long intervals, people become very paranoid that when the current train leaves, there might not be another for quite some time.
An important feature of Tezos is its ability to evolve without breaking its own rules. Tezos’ on-chain governance provides a neutral mechanism for stakeholders to coordinate and agree on updates to the protocol and its implementation.
Like many blockchain projects, Tezos is an open-source project with contributors from all over the world but, unlike other projects, it provides a mechanism through which anyone can credibly advance proposals w1ithout facing the typically insurmountable hurdle of coordinating a hard-fork.
Our teams, alongside many other contributors around the world, have historically collaborated on making ambitious proposals for the Tezos project. Going forward, we have decided to collaborate to submit protocol proposals every few months, which is the interval permitted by the Tezos on-chain amendment process. These will incorporate code that has been completed to our satisfaction by the scheduled date, rather than our introducing new proposals only when a predetermined set of features are finished.
The capacity to evolve is a key distinguishing feature of Tezos. With a scheduled releases approach, protocol proposals will occur with a much more steady cadence. We believe that this will, in turn, allow Tezos to gain the features developers and users have requested on a more dependable timeline.
