Thanks @Juansito for the clarity on the naming shift, especially moving away from “Council” to more functional terms like Committee and Program. That definitely helps.
That said, I’d like to surface a tension regarding the Operations Committee. It’s currently described as a
This sounds extremely close to what individual contributors within the Delegate Contribution Program would already be doing, especially roles like biz-dev, community, content, etc.
So I’m left wondering:
-
What “operations” would the Operations Committee execute that wouldn’t fall under scoped roles within the Delegate Contribution Program?
-
If their function is primarily supervisory or meta-coordination, is it worth electing a group for that, instead of assigning that work to capable contributors via roles?
-
If they are also executors, why not treat them as operational roles (with defined accountabilities and skill requirements), rather than bundling execution under an elected group where popularity can outweigh qualifications?
One first step is to clarify whether the Operations Committee is:
- Truly executing DAO programs (in which case they should just be structured as operational roles under the Delegate Contribution Program), or
- Coordinating the execution and communications among contributors; which in my opinion would make them more like a Support/Coordination layer (which was the initial reason why the Support Squad came into being in the first place.
).
Do you see why this is confusing to me?
I’d really love to better understand the rationale behind this division.
In my opinion, we should minimize elected groups to where deliberative or oversight functions are really needed (like the Accountability Committee), and let most execution flow through scoped roles and contribution programs.
Do others see additional nuances I’m missing? 