To avoid misunderstandings and to ensure that all ecosystem players have sufficient time to make a final/formal review, acceptance and implementation of a hard fork feature, we should define a relatively formal submission procedure. Prior to this procedure, it would make sense for the entity proposing a HF change to work with other people in the community who are “for” this change. I do not think that that process needs any formal definition. However, there needs to be some process that lets everyone else – people who are not interest in the feature, or see it as a lower priority than other items – know that the feature is “ready” for a final review/implementation, and gives those people the tools needed to conduct such work efficiently.
I’d like to propose the following components be supplied to enter this review phase:
- Specification of sufficient quality to allow implementation based solely on this spec (not code) and other “standard” specification (e.g. reference.cash).
- An implementation branched off of any full node that is currently tracking the BCH tip.
- A live testnet. This testnet does not need to exclusively implement the only this feature.
Any HF feature can be proposed with a “good failth” effort to implement the above items up to N months before the HF, and must be evaluated by us, with a decision made M months before the HF. Any feature proposed after N months before the HF is automatically deferred to the next HF.
If we end up with a formal body with members, I’d further add a rule that a deferred feature can be “rushed” into the current HF if every member but 2 wants to rush it. But this rule would require some kind of governing body that we don’t have right now.