These are in no particular order, and we understand that some may be more important than others, and some will require significant code changes to implement.
I will try to add some additional context from our discussions
RFC 35 Implementation - More Liquid Democracy: Conviction Voting Delegation Modifications polkadot-fellows/RFCs#35 – we have been told by members of the Polkadot Technical Fellowship (and others) that this will require significant code changes to implement, however we do believe that a more liquid form of voting is better.
Nomination Pool Stakers being able to vote and delegate in Polkadot OpenGov – some of our members have been stressing the importance of this for a while, and we do understand that this is being worked on, however, we believe it may be beneficial if other members of the Polkadot Technical Fellowship help to expedite this change.
Collaborative Decision Deposits – Some of the Decision Deposits for particular tracks are too high for the average community member to be able to post. If Decision Deposits were collaborative (i.e. multiple people can contribute towards it) then the broader community can feel more empowered to propose refs.
Reducing proxy.CreatePure deposit – the current deposit of 20 DOT is too high for the average DOT holder, this results in them not being able to use Pure Proxies. It would be great if this could be lowered to 2 DOT for example. Some of our members have reached out to Polkadot Technical Fellowship Fellows (of higher ranks) and they have stated that the 20 DOT value is arbitrary and can be changed.
Reducing generic proxy deposit (i.e. assigning gov proxy to your account) – see above pretty much
Reducing multisig txn deposit – a lot of our members often help other members of the community troubleshooting issues with multisigs, and by far the main issue is that people don't have 20 DOT on the account they are using which is part of a multisig. We feel like this number is arbitrary and should be lowered to 2 DOT for example.
Change it so that nomination pools as a whole have permissionless compounding, not so that individual nominators have to set it – most end users would like their staking rewards to be compounded. If they do not wish for them to be compounded then they should be able to set a different address as the staking rewards destination. Currently, as far as we understand it, someone on the network has to execute these compounding transactions which is rather expensive.
Lower treasury spend period from 24 days to something like 7 days (or even 24 hours, each ref goes through a really long approval process, this extra time delay is just prohibitive) - the spend period currently adds time delays for businesses building on top of Polkadot - we do understand that this affects inflation and burn mechanics.
Lower child bounty payout delays (to 24 hrs) – Bounties are a way for the community to be able to assign a set of curators to a specific portion of treasury funds – the current payout delay adds extra friction to those wishing to get funded from bounties and has caused issues in the past.
Lower Identity Deposit – we understand that on-chain identities are moving to a systems parachain, but we would like to ensure that the deposit is lowered from 20 DOT to something like 1 DOT, 20 DOT is simply too high.
I am posting this on behalf of a community and the above doesn't necessarily reflect my own views
GM, I am acting as the meatspace vehicle for ChaosDAO, here is a list of changes that we would like to see. https://github.com/paritytech/polkadot-sdk/issues/3901 is the impetus for this.
These are in no particular order, and we understand that some may be more important than others, and some will require significant code changes to implement.
I will try to add some additional context from our discussions
Lower Identity Deposit – we understand that on-chain identities are moving to a systems parachain, but we would like to ensure that the deposit is lowered from 20 DOT to something like 1 DOT, 20 DOT is simply too high.
I am posting this on behalf of a community and the above doesn't necessarily reflect my own views