I am not unhappy with Kusama’s configuration. However this is a reminder that everything we have once set can be evaluated once in a while. Feedback between various networks goes both ways.

I'm very much in favor of council being a body with more veto power and less active participation in the direction of the network (much to the chagrin of many of my fellow council members), and both of the changes proposed here are things that would move us in that direction, so they sound good from my perspective.

Then again, Kusama hasn't had as much of an issue with nonparticipation of council members in voting.

This is feedback that is probably relevant to Kulupu: (this is something we learned about on Edgeware, where the parameters are currently configured to require only 4 councilors to approve a treasury proposal) any threshold requiring low/less than majority approval may as well have a majority threshold - if I want to block council members from having the ability to "reject" my proposal, where rejection has < majority threshold, I simply put in a rejection motion with a majority threshold prior to making my approval motion.

or in concrete terms:

if Council membership is 20 people, the approval threshold is 1/2, and the rejection threshold is 1/4 - a council member with a contentious treasury proposal can simply put in their own motion to reject the proposal with a threshold of 10 (1/2) alongside the motion to approve the proposal, and then any attempts to create motions to reject with the true threshold (5) will fail due to the fact they are duplicates.

on no. 1: I am up for the idea of avoiding potential abuse by the council and therefore making it easier to reject, but i fear for "council paralysis" if treasury approval origin does not change alongside the former. We can definitely test the grounds with the next proposals, however active participation by the council for both ways (approve and reject) is needed.

on no. 2: although the council adds new tech comm members, isn't the definition of a member the one who has successfully implemented or specified either a Polkadot/Kusama runtime or Polkadot Host? im wondering if changing the election mechanism to democracy referendum really avoids collusion in kusama specifically - once the tech comm does more than just fast track runtime, separation is key, but maybe the answer is not so much on adding new members (who needs to fulfil certain criteria) and more on removing tech comm members (instead of council by referenda).