Change OpenGov configuration

[bkchr]

In RFC 20 there is some discussion about changing the certain parameters of the OpenGov configuration. In general the fellowship doesn't want to decide on these values on its own as this should be done by governance. Thus, the proposal is that we create a runtime upgrade that only enacts the proposed changes and then governance can decide if they want these changes by enacting the runtime upgrade or not.

The parameter changes can be done in the Polkadot/Kusama runtime itself. However we want to make sure that people that voted using the old locking periods on a referenda that gets enacted after the runtime upgrade get the locking period at the time of their vote getting enacted on chain. This will require some changes to the pallet itself to support this.

After all the changes are ready, the fellowship can create a release that only includes these changes and then propose it on chain.

[bkchr]

This will require some changes to the pallet itself to support this.

The best is probably to record the lockup multiplicator at time of voting and then store it in the state alongside the vote.

CC @ggwpez

[ggwpez]

Yea that would change the storage layout + migration, but probably not that bad. But i think that having a hardcoded enum for the convictions is not that good all together. Otherwise we force downstream users of the pallet to adopt our changes to the Conviction enum.
I prototyped this and it is backwards compatible paritytech/polkadot-sdk#125 (comment) without storage changes, since we already have the Conviction in storage.

But we can also evaluate that Convert at the time of voting and have both; stored duration+lock amount and a dynamic Convert for downstream users.

[bkchr]

Yeah, I think we could not only have the Conviction convert, as we don't want to allow new votes using the old conviction factors. Otherwise, making Conviction generic for downstream makes sense.