On Bounties Spending parameters - A Summary
Opening this post to read your thoughts on the parametrisation of the bounties proposal. I am summarizing below the few opinions read over the weekend in Kusama Direction - please add yours to this thread.
In general:
-
Bounties should span longer periods: the original specification was intended as a governance budget to earmark/budget future expenses. Such budgets should in principle be able to span up to period of a year (or longer but that sounds like a nice upper bound for now). Furthermore, the Council gets to approve everything, so it’d be nice to not be too prescriptive
-
Taken the below into account, bounty duration in the current design is basically just a required heartbeat duration and it doesn't actually describe how long the bounty lives unless the curator disappeared - in the current design you can extend the bounty if needed.
Parameters: https://github.com/paritytech/polkadot/pull/1336/files
Original treasury pallet extension discussion post: https://kusama.polkassembly.io/post/86
Comments (10)
I think bounties should last longer than 14 days, even with the extension call ready to use. A year might be a bit of a stretch, but it would not be crazy to think of bounties from 3 to 6 months, with the chance of extension. i don't think shorter than a year means the council is being prescriptive - but it gives us a bit more control over the funds allocated for specific tasks, and allows us to monitor the work of curators, especially in the beginning. if we want to think of this as a budgeting mechanism, i would definitely propose the bounty not to extend more than a year for practical reasons.
Do you think that it would make sense to increase the period to a month in this case? If a bounty is roughly 3-6 months then we currently have curators checking in onchain 6-12 times over the course of their bounty duration - I'm a daily user of the chain so I can't say whether that is a reasonable amount of activity or not, but increasing the period to monthly or bimonthly makes sense as a reasonable keepalive time for me.