Update tracks.rs

[Leemo94]

Changes to Treasurer, Big Spender, Medium Spender and Small Spender Confirmation Periods as per: polkadot-fellows/RFCs#20

I opted to not propose to remove the Big Spender track (it was part of the discussion on RFC 20) as I am not sure how it would affect referenda that are currently live on that Track.

[Leemo94]

I am also interested in understanding the way forward to propose changes to OpenGov track parameters on Kusama.
The tracks on Kusama are a bit different to those on Polkadot (Decision Periods are different) and I would like to propose to change the Confirmation Period of the Treasurer track on Kusama to 48 hours to match that of the Big Spender track.

Should I propose that change here?

https://github.com/Leemo94/runtimes/blob/9bbd9d2acfed9e6e9da7be4c6ecd6e0476a3c41f/relay/kusama/src/governance/tracks.rs#L119

[bkchr]

Should I propose that change here?

https://github.com/Leemo94/runtimes/blob/9bbd9d2acfed9e6e9da7be4c6ecd6e0476a3c41f/relay/kusama/src/governance/tracks.rs#L119

If you like you can include it in this PR directly.

[adamsteeber]

This needs to be accompanied either by an increase in the payout delay for bounties or a much faster track solely for assigning bounty curators. Right now, the delay is 8 days. If my understanding is correct, this delay serves as an opportunity for openGov to respond to a compromised curator attempting to misuse bounty funds. If the Treasurer track takes 7 days to confirm, it will be rendered effectively useless against a corrupt curator who can heist a bounty with a mere 8-days notice.

[joepetrowski]

This needs to be accompanied either by an increase in the payout delay for bounties or a much faster track solely for assigning bounty curators. Right now, the delay is 8 days. If my understanding is correct, this delay serves as an opportunity for openGov to respond to a compromised curator attempting to misuse bounty funds. If the Treasurer track takes 7 days to confirm, it will be rendered effectively useless against a corrupt curator who can heist a bounty with a mere 8-days notice.

We should probably do away with this delay on bounty payout. It was not related to the confirmation period but rather the Council motion duration back in the day, which was 7 days. A confirmation period of 1 day vs. 7 days is irrelevant when the track takes 28 days to decide; it's still outside the bounty delay. The network should really only give bounties to curators it has a reasonable expectation to curate. Or, better yet, use a sub-treasury with more transparent voting and membership criteria.

From Bounty pallet:

//! After the Council has activated a bounty, it delegates the work that requires expertise to a
//! curator in exchange of a deposit. Once the curator accepts the bounty, they get to close the
//! active bounty. Closing the active bounty enacts a delayed payout to the payout address, the
//! curator fee and the return of the curator deposit. The delay allows for intervention through
//! regular democracy. The Council gets to unassign the curator, resulting in a new curator
//! election. The Council also gets to cancel the bounty if deemed necessary before assigning a
//! curator or once the bounty is active or payout is pending, resulting in the slash of the
//! curator's deposit.

[adamsteeber]

We should probably do away with this delay on bounty payout. It was not related to the confirmation period but rather the Council motion duration back in the day, which was 7 days. A confirmation period of 1 day vs. 7 days is irrelevant when the track takes 28 days to decide; it's still outside the bounty delay. The network should really only give bounties to curators it has a reasonable expectation to curate. Or, better yet, use a sub-treasury with more transparent voting and membership criteria.

Gotcha, I just assumed that this delay period translated directly to openGov. As you mentioned with the 28-day decision period, the mismatch between that and the 8-day delay confused me.

I suppose we expect openGov to thoroughly vet curators with less trust than what the old Council had in curators. As long as you don't think we need an agile track for curator management, this is all good enough for me.

[muharem]

in the comments to the RFC, we also discuss a possible update to the conviction factor, treasurer curves and the confirmation period for the root track. are we going to proceed with that RFC? should we summarize all those comments into the final table with all paramaters for kusama and polkadot, and the conviction factor.