Cosmos Hub Improvement Process (CHIPs) Revision

Last year, we introduced the Cosmos Hub Improvement Process (CHIPs) as a framework for making technical changes to the Cosmos Hub. Since then, we have used this framework to improve the collaboration and communication with the Cosmos Hub community.

Although the benefits of using CHIPs are evident, we believe that a revised version would bring more clarity on the concerns that we are trying to address with this framework. Thus, we proposed the following two-stage process.

  • First, a design stage that facilitates collaborative product development within the Cosmos Hub community. The design stage consist of three phases.

    1. Discussion Phase: An idea is proposed and discussed on the Cosmos Hub forum. This proposal can be looser or higher level, but introduces and describes an idea, research direction, or feature. Depending on the outcome of this discussion, authors can evaluate if it is a good idea to put more time into the project.
    2. Signaling Phase: A signaling proposal is submitted to Cosmos Hub Forum and then Hub governance. This proposal is informed by the feedback gathered during the discussion phase and is intended to gauge the community’s willingness to deploy the feature on the Cosmos Hub. To enable the community to engage in the voting process, the signaling proposal should contain a design document providing detailed information on the proposed feature (i.e., an ADR or/and a specification). If needed, the authors can create a prototype implementation (i.e., a spike) to gain additional information about the feasibility and design of the feature, however, this is not mandatory.
    3. Implementation Phase: Once the on-chain signaling proposal passes, the specified feature is being implemented and tested using best practices.
  • Second, a deployment stage that standardizes the process of adding new features on the Cosmos Hub. The deployment stage consist of three phases.

    1. Integration Phase: A new feature is integrated into Gaia. This phase has a set of prerequisites. In general, all new features need to go through a signaling phase — the community needs to agree to deploy it on the Cosmos Hub. Also, additional integration tests are usually needed. Finally, depending on the impact the feature might have on the security of the Cosmos Hub, a security audit might also be required.
    2. Testnet Phase: A Gaia release candidate (potentially including multiple features) is cut and used to upgrade the Cosmos Hub public testnet. This phase may require multiple release candidates and testnet upgrades.
    3. Governance Phase: A software upgrade proposal is submitted to and voted on by the Cosmos Hub governance. If the proposal passes, the Cosmos Hub is upgraded through a coordinated upgrade.

To summarize, these are the changes from the original CHIPs post:

  • The specification, spike, and signaling phases were combined in a single signaling phase.
  • The voting and deployment phase were combined in a single governance phase.
  • The maintenance phase was removed as we believe it requires a deeper discussion. We plan to open a separate thread soon.

We are definitely aligned with this proposition. As a constructive feedback regarding the post itself, we would recommend detailing the modifications you made, it would make it easier for general users to understand what you changed. To showcase one example, the post could have mention the deletion of the Specification & Spike Phases, which we also think could be removed to simplify the whole process.

Anyway beside the post itself, we reiterate that these changes are a net improvement and we definitely support them.

1 Like

Thanks for the feedback. I updated the post.