This document will ensure that everyone is more or less aligned in what we build for BCH. We should mention specific technologies if possible, with the understanding that a demonstrably better technology could replace it. But the onus would be on the new tech to prove its better, and vaporware is not demonstrable :-).
Having this basic agreement will prevent a lot of problems that derailed the first few years in BCH, and stop a lot of wasted effort. We need to move quickly and efficiently now to make up for lost time, not fully investigate many possible ideas and then reject most of them simply because that’s not where we want BCH to go.
Should we even do smart contracts? We should not be debating this topic within the confines of a specific technical proposal to increase the P2SH script size. If we are not even doing smart contracts, the engineers who spent a few months creating a proposal to increase the P2SH script size should not have been wasting their time. This is how engineers leave the ecosystem.
Should we do smart contracts in BCH script, or should we make a completely new language for them such as web assembly. You can see how a tremendous amount of wasted work will happen if we chase down both of these roads, but the end result will be more or less the same from the user’s perspective since they are coding in higher level languages. And if all the engineers had piled onto one or the other, we’d be much further down that path. This is an example of why the roadmap should commit to specific technologies, when possible.
Finally, such a document would give something for people to get excited about, about the “new BCH leadership”, and also communicate that our more democratic process won’t get bogged down with no progress (which is a common criticism of more democratic processes verses the dictator model).