With Bounties nearly implemented I want to share this. It is up to the Council to decide what to do with it.

With Bounties I firmly believe this community has gained a powerful instrument to channel its agency. I.e. it gains an instrument to set goals and allocate financial resources. Remunerating development activities is but one of the activities that makes a project successful though. The remuneration for the project manager with the Curator Fee is one step in the good direction. And Sub-Bounties allowing for milestone approaches to remunerate design phases is another step in the right direction.

I am not in a habit of asking for remuneration and I certainly have not ever done so on a personal title. That said I spent at least 40 hours (give or take: https://github.com/paritytech/substrate/issues/5713) on writing the original specification of Bounties. And if we judge this specification at face-value we have not deviated that much from this specification.

I would appreciate a Tip for this work. I would be perfectly fine with this remuneration going towards the Polkascan Foundation Multisig (DWUAQt9zcpnQt5dT48NwWbJuxQ78vKRK9PRkHDkGDn9TJ1j).
Remunerating this multisig will ensure the KSM will be spent on a good cause legally bound by the by-laws of Polkascan Foundation.

Bounty Instrument Original Specification

I would strongly favor giving the ElectionsPhragmen.DesiredRunnersUp constant a higher value in the next runtime upgrade.
https://polkascan.io/kusama/runtime-constant/2022-electionsphragmen-DesiredRunnersUp
That will allow more visibility to candidates and would prepare for an eventual higher Council Membership.
This should be a minor change that can go into the next runtime upgrade.

In addition I would not mind a discussion on the pros/cons of moving from 17 to 19 Council Members (ElectionsPhragmen.DesiredRunnersUp constant). 
https://polkascan.io/kusama/runtime-constant/2022-electionsphragmen-DesiredMembers
I have no strong opinions here.

Council DesiredRunnersUp and DesiredMembers

Wei Tang has made a few interesting points in tweaking Kulupu governance settings. In particular: 

1. Lowering the Treasury Reject Origin to 1/5. This affects it is easier to reject treasury proposals limiting chances of abuse by the Council. 

2. Address a separation of duty between Council and Technical Committee. This affects a collusion risk between these both on-chain institutions. 

The key difference with Kusama is that we have somewhat formalized the requirements to be a member of Technical Committee. 

I’d like some opinions of our Council on these points in relation to Kusama. 

Details: 
https://github.com/kulupu/kulupu/pull/41

Tweaking council authority

We resubmitted our Polkascan Foundation candidacy for Council. 

We changed the account. It is now a 2/3 Multisig account which better reflects the Polkascan Foundation Board's voting structure.

We intend to continue our active role on the Council once re-elected.

In general we will focus on:

1. More effective governance mechanisms (on Kusama)
2. Monitoring and intervention related to the health of the chain (Kusama)
3. Setting best-practices for ecosystem service providers (on Kusama)

We would appreciate your renewed support to get us on the Council, which requires ~65000 KSM backing.
Or at the very least we'd like to be on the Runners Up list which requires ~7000 KSM backing.

You can vote on us here: https://polkadot.js.org/apps/#/council

No tip found