Interesting experiment. One issue we see is that having the support threshold as high as suggested would make it very difficult (if not almost impossible) for most refs to pass. However, we know that these parameters can be changed in the future. We do support raising the deposit requirements to make it easier to prevent spam.

I was initially aye, but switching to nay after further consideration. I find max deciding counts too low compared to historical activity, especially in medium spender. The Ionian's comments are very valuable. Especially the concern regarding applying such an overarching change all at once, without first demonstrating success on Kusama.

Support this changes!

These adjustments appear to be a good way of improving the quality of OpenGov by reducing spam proposals and voter fatigue. Aye.

I have worries the max deciding is too low and projects may wait months for their proposals, but this proposal turns OpenGov to right direction.

Interested to see tokenholder votes on this and hopefully will have a large turnout

I'm against most of these changes but not categorically. I think they've done a good job on identifying the problems in OpenGov but the solutions are palliative at best. I would like to see futureproof solutions instead, a few thoughts:

1. Why not set a dynamic decision deposit based on the circulating supply of DOT? Are we going to update this every few years?
2. Fewer active proposals will make clogging the tracks very easy and cheap, I understand this is less of an issue with reduced decision time but still doesn't make sense to reduce it so drastically.
3. Cancelling bad proposals: I like this one, no further comments.
4. So based on the latest arguments that "oh people have OpenGov" burnout, also put forward by the proposer, this makes even less sense as it will push people to vote quicker and put even more pressure on holders so this make VERY little sense to me.

These changes don't seem smart at all if I'm being honest, also the support requirements are not implemented in a smart way. Why not take the rolling average of the last 4 weeks of OpenGov participation (or 3 months or 6 months whatever) and use that as the turnout requirement, this way it would be dynamic and follow the trend of OpenGov participation. Having static requirements when all of this can be easily adjusted by code dynamically is just not very smart.

Also, why are we making such sweeping changes ALL AT ONCE? Why not start on Kusama with some of these, or start by more controlled, smaller changes then observe OpenGov for 3 months and propose more. I don't understand why it has to be ALL OR NOTHING.

Personally, I have very mixed feelings about this new approach.
On the one hand, I welcome the attempt to reduce voter fatigue in OpenGov and thus increase the pressure for better quality proposals in governance.
However, I also find it negative that the maximum number of proposals may be very low, which could result in many interesting projects being left out.
I remain abstaining.

This could be a great way to help OpenGov run more effectively