feat: ICRC-0: Governance of IC technical working groups

[dietersommer]

No description provided.

[legendface66]

The issue with the comparison of the IETF & the DFINITY community is that the IETF themselves implement changes to their specifications and guidelines via rough consensus. Following this, adoption of their specifications and guidelines takes the form of a rough consensus in the market.
For the IC, however, we don't have a secondary rough consensus. Instead, we use the NNS which provides hard consensus.
For this reason, working group consensus is secondary to NNS consensus.
The focus of Working Groups needs to be on establishing consensus among neurons, not on consensus within working groups. More on this further down.

In the governance working group we have found that several groups have split off to perform different tasks in what we have called sub-working groups. These groups report on their work to the overall working group once work items have been completed and are ready for review.

As NNS consensus holds primacy over working group consensus, it is important to preserve a clear statement of the technical issues and differing perspectives on those issues for neurons to read and understand. These issues need to also contain faithful tl;dr summaries because otherwise neuron engagement is difficult

The governance working group has found github challenging so we are using google docs - just a point.
For presenting information to neurons, a more friendly medium will work better than github - A shared google doc, or more appropriately a PDF so that neuron commentary or feedback can be tied to a static document.

It is important to capture all objections because these connections will emerge in the mind of neuron holders while they make their decision. objections need to be included in documentation supporting the proposal and answers/responses to those objections also included to save on public deliberation of already resolved issues.

It is important to make all of these perspectives available to neurons to understand. The best thing is to include evidence so that public deliberation can lean on prior art or be supported by hard fact.

Belaboring the point, capturing the reasons for objections as they come up is extremely valuable as these objections can be expected to come up in the minds of neurons.

Rather than passing a proposal from the working group to the NNS, a better way is to package all of the work that has taken place into a series of easily readable documents and present the work to a meeting of neuron holders. This gives an opportunity for the neurons' questions to be raised and answered, feedback given, and integrated before the proposal is created. This way conflict in the community over proposals can be minimised. Partly because the objections and responses can be worked through in a public setting, partly because feedback can be taken on in advance.
It might also make sense to allow at least one week to pass after the neuron presentation. This is to allow discussions on social media, time for honest integration of feedback, and time to write the proposal as it will be submitted to the NNS.
It is also advisable to have an open community presentation upon submission of the proposal so that everyone knows what is going on.
This is not the opinion of the GWG, just one person. What is presented here is much more advanced than where we have got to.

This looks fantastic to me. The issues raised relate to capturing perspectives, sharing them with neurons and the community, gathering feedback, and delaying the creation of a proposal until after feedback has been gathered and the community has been educated.