Note: Thanks to Marius Poke for initiating the development of this process.
Summary
This proposal seeks to ratify a framework for making technical changes to the Cosmos Hub. We hope that this will encourage more developers to contribute to the Hub, and ground all feature-oriented governance discussions in software development best practices.
Phases
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.
Specification Phase: A design document is created providing detailed information on the proposed feature. The outcome should be a Cosmos Hub Improvement Proposal (CHIP) following the document format defined in https://github.com/cosmos/cips. At this point, the specification is a first draft. It will likely be changed during the Spike, Signaling, and Implementation phases.
Spike Phase: A prototype implementation of the feature is created that enables better estimation of the expected timeline. This implementation is not expected to be fully finished or hardened for production, but is intended to gain additional information about the feasibility and design of the feature.
Signaling Phase: A signaling proposal is submitted to Cosmos Hub Forum and then Hub governance. This proposal is informed by the information gathered during the Spike phase and is intended to gauge the community’s willingness to deploy the feature on the Hub. If the community does not have enough information to decide based on information gained from the Spike phase, the project should either go back to the earlier phases, or be abandoned.
Implementation Phase: The specified feature is being implemented and tested using CI practices.
Integration Phase: The implemented feature is integrated into Gaia. Note that this phase may require additional testing.
Testnet Phase: A release candidate is cut and used to upgrade the public testnet. This phase may require multiple release candidates and testnet upgrades.
Voting Phase: A software upgrade proposal is submitted to and voted on by the Hub governance.
Deployment Phase: The Cosmos Hub is upgraded through a coordinated upgrade.
Maintenance Phase: The software for this feature is continuously maintained, patched, and upgraded for as long as it is on the Hub. It is critical that this phase be considered carefully and resources allocated to it during the earlier phases.
Notes:
In phase 2, we reference the CIP format. This is mostly a document format for detailed specification of features. The CIP repo also contains a process for editing the document, which we expect will be followed in parallel with the process defined here, but will mostly take place in phases 2 and 3 of this process.
Phases 7 to 9 take around 1 month. As a result, the plan is to have semi-quarterly upgrades of Gaia.
To reduce the impact on the operators of mainnet validators, the mainnet upgrade is scheduled usually on a Wednesday at 15:00 UTC.
The Voting Phase depends on the Cosmos Hub voting period (currently set to 14 days). To allow for inaccuracies in upgrade height estimations, the software upgrade proposals are usually submitted on a Thursday or Friday, two weeks and a half before the upgrade.
To reduce the impact on the operators of testnet validators, the testnet upgrade is scheduled usually on a Wednesday. As a result, a release candidate is expected to be available on the previous Friday.
Following up after our initial call with Brian Traux,
Some questions/suggestions:
Is this only focused towards the hub and not AEZ? For example an Sdk module implementation in the hub.
Can this be supplementary or a preliminary approach for teams approaching grant programs such as AADAO to discuss the scope of the project, dev costs, maintenance costs, and overall importance of the project to make sense for the hub.
Perhaps a more technical more detailed explanation or scoping of the Chips process, and maybe more collaborations with subdaos such as grant teams for teams.
A slight concern is the centralization/authority of being just Informal who steers this ship as gatekeepers of developing on the hub (ie conflicts of interest, competition, or biased opinions for/against it). Perhaps involving additional members outside of Informal may provide a more neutral approach.
Overall I think its a great initiative in terms of more technical oversight as we do want the hub to be protected but as the same time not prevent development towards it.
There was a guy in a previous post that wanted 50% of funds to be distributed for “forum post”, which is obviously ridiculous. The way funding should work is like this:
5% distributed after Discussion Phase passes (in order to fund writing of CHIP). Money should be disbursed to a “business analyst” role of project.
20% distributed after Specification Phase passes, ie CHIP proposal is written and passes (in order to fund spike and signaling phase). 75% of this lot should be disbursed to “developer” of project and 25% to a “business analyst” (for further refinements)
50% distributed after Signaling Phase passes (in order to fund implementation and integration). This money should be disbursed to “development team” of project.
20% distributed after Integration Phase passes (in order to fund Testnet, voting and deployment). 90% of this should be disbursed to “quality assurance”/QA team and 10% to a “build”/“deployment” team.
5% distributed after Deployment Phase passes. This should be disbursed to “build”/“deployment” team.
Maintenance should be in a separate budget that encompasses all deployed features.
Yea, this is focused on the Hub. We wanted to make sure that discussion stays centered around things that have a specific benefit for the Hub, not just cool Cosmos projects in general.
Yea, that would be great. We hope that this can be a good starting point for a shared process and any suggested changes to make it work better for other people are welcome.
Not sure what you’re referring to exactly, but I imagine that once we have put several items through this we will have a lot of things that will need to be changed with the real life experience.
This is a process we are suggesting. We would love to get suggestions on how to change it, and we don’t have any particular role in it. That being said, we may comment with our professional opinions on items during various stages of CHIPs, but that is purely our opinion. We are not in charge of anything other than our own work.
love that you want to introduce a framework for making technical changes to the Cosmos Hub.
If I understood your prosoal correctly all steps would be completed by the same contributer. It might make sense though to seperate the Idea and Execution phase. Even non technical persons or people without the proper capacity could have great ideas that could be executed by other teams.
Because of that adding a tender phase which allows dev teams to apply for the execution could make sense.
Upon review, we find our sentiments closely align with the insightful feedback provided by @CuriousJ, particularly in recognizing the existing overlap with some AADAO tasks. This alignment underscores the importance of streamlining processes for efficient collaboration within the Cosmos ecosystem.
Furthermore, we would like to underscore the strategic significance of considering CHIPs as a prerequisite for any chain joining the AEZ. This approach would establish a shared technical risk baseline, significantly enhancing the overall user experience and ensuring the safety of funds within the Atom economic area.
Thank you once again for your valuable contribution to the ongoing development of the Cosmos Hub.
