Cross posting my thinking on from github
my two lovelace
I feel that the CIP process is a good place to improve the collaboration between Cardano node teams.
The IO haskell teams have been increasingly engaged in the CIP process, with core teams documenting major changes as well as dedicating time to reviewing community proposals.
From my perspective this has been great for all.
I feel that it would benefit all for this to continue and expand, to include engagement all node teams.
Without strong collaboration mechanisms we risk losing the benefits of a multi-node ecosystem.
This can only work if all teams are actively dedicating time to collaboration, with some of that through the CIP process.
and maybe the CIP process isn’t the best place for this majority of the collaboration, but thats okay we will work it out as we go.
What can we do in the CIP process to improve things?
I feel we should re-define the core categories (those will require close collaboration between node teams)
so that these categories clearly define what sort of changes must be documented and which do not need it
this places guardrails on changes to core areas.
This will require all teams to work together on adding necessary guardrails within Plutus (CIP-35), Ledger (CIP-84), Consensus (CIPending), Networking (CIPending).
for example; all changes to ledger’s serialisation, historically have not been documented via CIPs, but as it affects how nodes communicate, it should probably be documented moving forward.
Additionally, we should add tighter criteria on how CIPs in these cateogires become status: active.
i.e. all teams should probably sign off on an active status.
I would stress that we all will need to be stricter about the enforcement of agreed category guardrails.
Why like this?
One step at a time.
I like that the CIP process is slow.
I would avoid making big changes or adding a new type of CIP.
I feel its better to improve one small step at a time.
If we agree on the first step, we can then think about the next step.
One reasonable suggestion is creating different lanes or levels of core CIP,
where changes are differentiated and held to different standards based on their scale.
How can we make sure this will work?
We need to ensure that these core teams, have bought into this process.
they all MUST contribute, and agree on all important changes or this process does not work.
This will involve changes in working procedures for the IO Haskell teams.