Hello, Everyone!
I am going to submit a proposal to reduce governance voting period.
The value will change from 14 days to 7 days.
Why I need change this value?
I think the current value for voting period is too long, we have to spend too much time on waiting the period to be end. 7 days is reasonable.
Appreciate for your feedback.
You can visit LOOK explorer to query all parameters
Hi! Thanks for sharing LOOK Explorer–great resource, I’ve bookmarked it.
For some proposals the voting period can be a bit long, agreed, but I think that it’s a good thing.
What happens if there’s little or no off-chain discussion prior to a proposal going live? The current two-week period gives stakeholders the opportunity to 1) see the proposal 2) ensure they discuss and understand the implications together with any potential teammates 3) discuss the proposal with the broader community and potentially revise their understanding prior to voting.
For example, I could see a scenario where a big player quietly launches a proposed change that’s controversial. I have other responsibilities, so it could take me a week to publish a well-thought-out position on that proposal.
It’s a big network with many stakeholders, and governance proposals are about to get very powerful. I don’t see why we can’t wait two weeks 
I agree with Gavin, I think the 14 day proposal time is good. There is really no need to rush, and a full review is helpful.
While for some minor proposals the voting period may be too long, I also consider that for the time being the 14 days period is OK overall. Let’s not forget that we are still in early stages and having more time is better.
Also, another important aspect that needs to be taken into consideration is the fact that from what I saw the validators on most of the PoS chains are pretty much the same people and the level of work and load per human resources increases everyday. Having more days might permit us to identify eventually unexpected flaws or errors in different proposals. From my opinion we should keep the voting period parameter as it is for the time being.
Thanks!
Thanks, @Gavin @Gregory @syncnode
We have been waiting CosmosHub 3 upgrade for over a month(I didn’t count the exact number). It’s too long, isn’t it? Since we still in the early stage. we need make decisions as fast as possible.
@syncnode I know many people run validator for many chains. Every team have limit resources, We should have a selection from so many pos chains.
@Gavin The most proposals might have enough discussion before vote.
If this really happens. I think we will have enough votes to veto that proposal in 7 days.
I think it’s too soon to change this lever.
There are other ways to speed up governance: draft proposals or help drafting them, help gather opinions from different stakeholders, and gather the necessary votes to push proposals through quorum. For the past few Hub 3 upgrade related proposals, it feels like it’s been mostly Gavin doing the heavy lifting.
thanks @JK_bitfish for sharing your opinion.
I wouldn’t support this change either.
7 days might be just enough time for validators to make up their minds, vote and write a disclosure to delegator on reasons behind their vote. It might be sufficient for nominal changes such as sdk version but wouldn’t be enough for other “opinion-based” decision.
We, as validators, constantly keeping up with the news and network developments. The majority of validators need time to discover those proposals and digest all possible implications. If the goal is to increase non-valaidator participation in governance, the 2 weeks window should stay.
I’m generally in agreement with @Gavin and others here, I think we shouldn’t make the governance period be strictly 7 days long.
However, what I would like us to think about it ways of making it such that the governance period is variable. I’m not sure a single fixed governance period is the right method in the long term.
One example, perhaps might be having a specific minimum voting period (for example 7 days), but then there is a mechanism to extend the voting period. As an example, let’s say anyone can send an ExtendVotingPeriodMsg, and each 1% of voting power can extend by say 24 hours. That way, let’s say 10% of the voting power thinks the period needs to be extended, they can unilaterally extend it by ~ a week. If it’s a really controversial thing or something that needs lots of consideration, it can be extended up to even ~3 months by 90% of voting power.
This is just a toy example of a possible design, but would love to hear some other ideas for mechanisms to create variable periods.
I think the current 14-day voting period is just fine. 7-day period is instead too short. Although we see a lot of discussions on TG or this forum, mostly they are comments from validators. Other ATOM holders usually don’t realize there is a proposal until the proposal is being submitted. We also need to let the delegators have enough time to review the vote of the validators and consider overriding the vote.
The most validators don’t support this proposal, I would NOT submit it to the chain. Unless there are more than three supporters from validators/delegators.
I really think variable periods is a good option.
@ping Want to work together on writing an ADR to design a variable periods mechanism? (or anyone else interested)
Keep me in the loop? I’d like to see some sort of option for expedited proposals. Hopefully I can provide some useful feedback.
Ok. Let me write a draft for it and I don’t think my english is good enough to write formal document. So I need your guys to help me finish that.