Feedback from a quick reading (not getting into the weeds) of the proposal.
After this proposal is passed and after successful testing, and after the software Git hash for v0.34.0 has been finalized, conduct a second proposal which includes the specific Git hash, using an expedited governance rule to determine acceptance.
I don’t immediately see the benefit of having a placeholder proposal for the sake of having a proposal. The wheels are in motion for 0.34.0 software and testnets with transfers - any proposal should wait until the software is out to indicate the upgrade path.
In order not to unduly delay the release process, a two-step governance setup is being proposed, in the next section, for the release of v0.34.0. Before proceeding, let we define:
As a voter - I’d prefer to see a this as a separate proposal. I may support transfers but not expedited governance or vice versa. By bundling these together I have to decide which is more important to me when I vote. By separating, I can vote on each as desired.
The community accepts the current release (v0.33.0) of the Cosmos SDK running on chain cosmoshub-1 as stable;
Isn’t this the de-facto currently? Separately - does it matter that we accept this or not? I only mention it to highlight that a proposal which reduces noise is easier to grok.
Proposed upgrade process
Is this necessary to list in this proposal given that there will be another proposal with 0.34.0 and the actual upgrade vote? Circles back to what this proposal is trying to accomplish and whether it is even necessary. The broader community is aware that efforts are moving towards enabling transfers. I would be in favor of 1) smaller scoped proposals and 2) waiting until 0.34.0 is released and adjusting the proposal to describe the actual upgrade.