Committee-Based Governance on the Internet Computer

What does it mean to have effective governance?

In the prior post on the “Year of cycle_dao” we encountered two primary governance dilemmas:

1. Should you make decisions based on what you feel is best, the preferences of your voting constituency, or the affected parties as a whole (the community)?
2. How do you determine what these groups want? How do you effectively inform yourself and develop a course of action?
   

To answer these questions we need to step outside the frame and recognise that decision-making does not take place by voting. Voting is how legitimacy is established. Decision-making takes place during the proposal creation process. By effectively engaging with both the voting constituency (neuron holders) and the community (actual ecosystem participants, not keyboard warriors on social media), the best decision will make itself clear.

The best decision solves a problem but does not stress Loyalty enough to induce Exit in community members. [See Back to Badlands]

The best way to engage these groups is to move responsibility for the market research component of proposal creation away from DFINITY and onto them. By doing so we can reposition DFINITY from IC community leader to tool for the Internet Computer (henceforth IC) community to realise the platform they want to be building on. In this world, DFINITY operates in the background and the community is the star of the show.

The NNS gives us a mechanism to achieve this. However, we need to create an accountability structure for the community to operate within. We need to abandon ad hoc governance and learn from other communities that have solved this problem before.

The ISO

Collective decision-making of the kind the IC community needs to engage in has a number of precedents. One example is the ISO (International Organization for Standardization) and its international standards development process. The ISO is an organisation made up of participating national organisations ie. ANSI (The American National Standards Institute), Standards Australia, Standards New Zealand, - most countries have a representative body. These national organisations are themselves made up of regional industry participants: businesses, NGOs, and educational organisations.

The standard creation process begins with a proposal for a new standard to be created that is submitted to the ISO by a member such as ANSI. If the proposal is accepted an international Technical Committee of delegates is formed. These delegates are industry participants from the particular nation they are representing.

This Technical Committee forms one or more Working Groups to research and iteratively develop a standard. Once the Technical Committee achieves consensus on a standard they pass the standard to the ISO where it is voted on by member nations. A more detailed description of the process can be found here.

The two major structures that exist within the ISO standards development process are the Technical Committee which is formed to oversee the development of an individual standard, and afterwards disbanded, and the Working Group, usually multiple of which are formed by the Technical Committee to work on individual components of a standard.

While this structure is rigid and at times cumbersome, its focus on a step-based process where the deliverables of each step are fed into the following is designed to eliminate the coordination problems associated with ad hoc or market-based decision-making. Global standards benefit tremendously from general buy-in - it’s not a standard if people choose not to use it. The experience of cycle_dao and early contentious NNS votes has taught us that the IC suffers from these coordination issues. Like international standards, Internet Computer’s NNS needs to achieve general buy-in to the decisions that it makes or risk ejecting ecosystem participants (Exit from the Back to Badlands post).

Establishing Such a System in Internet Computer Governance

Followee neurons have the power to import a similar process into NNS governance by publicising a set of requirements, or checklist items, for a proposal to be eligible for Adoption. If these requirements are not met, the proposal can be automatically Rejected without consideration. The IC is a multi-billion dollar computing platform. If someone can't be bothered backing their proposal with evidence and an impact analysis it’s fine to reject it out of hand. Even if it’s coming from DFINITY. That said, the community should be providing the evidence and impact analysis to DFINITY so they can more efficiently allocate their resources. The rest of this post will describe what those requirements might look like and the process for assembling them.

The next post in this series, General Policy Creation for the Internet Computer, will illustrate why such strictures are necessary, why their absence has caused problems for the IC and the native token ICP, and why without them the IC is likely to run into more trouble in the future. It will also discuss how the process described here naturally streamlines itself over time leading to more rapid proposal development and how it can be accelerated for rapid action in emergencies.

Process and Checklist Items

Checklist Item #1: Identification

A clear statement of what the problem is, a list of links to primary resources indicating the problem exists, and an initial statement of the goals a proposal to remedy the problem should have

The Identification document should contain summaries of and links to discussions on the forums, social media, offline conversations, stakeholder surveys, blog posts, etc. that indicate the need for a change to the IC. This identification document could come from inside the foundation, or outside. It could call for a fix, an upgrade, or a configuration change. Its purpose is to establish a genesis point for the development of a proposal. As a rule of thumb, stronger identification indicates a greater need for a proposal and provides justification for further consideration and effort.

This is in essence what we see happening in the governance section of the DFINITY Developer Forum today. However, to validate this, supporting content from other sources is necessary - simply relying on forum discussion is not enough. There should be a well-assembled body of evidence to support the creation of a proposal.

This document should be short and sweet - less than one page. It is analogous to a proposal for a new standard to be created in the ISO’s system.

Checklist Item #2: Reporting & Impact Assessment

A committee representing concerned parties is convened to produce a report on whether a change should be implemented and a recommendation for what that change should look like. Teams building on the IC have an incentive to provide a delegate to committees working on proposals relevant to them. There are a number of well-funded teams building on the IC - InfinitySwap, Origin, Toniq, Fleek, DSCVR, Distrikt and others. It is important that individuals do not participate on their own, but rather represent an organisation to which they are accountable. If you’ve seen open public policy submission hearings you’ll understand the need to filter participation through organisations. It ensures professionalism, commitment to the process, and accountability.

Report

The creation of reports requires research and deliberation. The committee can break research tasks down by subject matter and assign these to internally created Working Groups. Once a research task is complete, Working Groups report their findings back to the Committee. These are used as support for overall deliberation.

The findings are captured in a report and a course of action is recommended. Because there may be dissent about the course of action, the Committee should indicate the degree of support via member signoff. In the event there is a significant divergence of opinion within the Committee (eg: 70% to 30% split), a majority report should not be considered valid without a corresponding minority report to clarify the opposing perspective. Supporting documents such as original research, focus group reports, recordings of committee meetings, transcripts, minutes, notes, etc. should be included as addenda.

Impact Assessment

An Impact Assessment also needs to be produced to identify potential externalities of the recommended changes. In the next post on Policy Creation, the fundamental importance of impact assessment will be explored.

Checklist Item #3: Mandate

A mandate for a change to the IC is produced either by the committee or by another party. This mandate directly references the identification document, reports, and impact assessment. The mandate is a clear description of the change required and the design envelop within which it is to be implemented. This should include specifics like the maximum amount of resources to be assigned to implementing the change, its priority relative to other ongoing work, allowable IC performance impacts, unacceptable outcomes, etc.

Public comment on this document is solicited. These comments are recorded and their feedback is addended to the mandate as reference material, just like the committee’s report/s, impact assessments, and identification material.

Checklist Item #4: Approved Statement of Work

A protocol development group (DFINITY)  responds to the mandate. The response is either a qualified rejection (too resource intensive, silly, etc.) or a Statement of Work (SoW). In addition to responding to the content of the mandate, an SoW should include estimates of the total resources the work is expected to consume, its proportional consumption of the total resources available, and a timeline for development. This is important because the cost of implementation must be weighed against the relative importance of other changes. This is a key proposal data point regularly requested by NNS participants.

Some collaboration between DFINITY and the committee should be expected in the process of creating an SoW. In some cases, it is likely that the mandate itself needs to be revised to fit what is possible. In these cases, it is important that the reasons for any changes to the mandate are recorded and the updated mandate opened for public discussion. It is acceptable for the SoW to be developed at the same time as the mandate is revised.

Ultimately, the SoW is either approved, rejected, or scheduled for review at a later date. This determination is made by the committee that developed the reports and impact assessment as the members are assumed to be the leading experts on the issue under discussion. If the SoW is rejected or scheduled by the committee, clear reasoning must be given.

Checklist Item #5: Townhall, Motion Proposal, Submission

A motion proposal referencing the documents created through this process is created and published by DFINITY. The committee indicates its support or opposition (this is to publicly indicate that the proposal accurately represents the SoW. It is a necessary formality to save neuron holders the effort of reading through everything). An open town hall discussion of the proposal is conducted to ensure the community understands what they are voting on and its consequences.

After a cooldown period, of several days or weeks, the motion proposal is submitted to the NNS for a vote. If the motion is rejected, that’s the end of it. If it is adopted work can begin.

This sounds like a lot of work. However, it does not need to be implemented in one stroke. It will be enough to begin with a committee of delegates all of whom are prepared to actually do structured work. This puts governance in the hands of professional stakeholder representatives working inside a formal structure. That structure will evolve in its own direction over time.

The reason the process is described so formally here is to assemble the necessary steps in stakeholder consultation, policy creation, and product development - all of which are important parts of NNS proposal development.

Conclusion

First a word to those who see this process as excessively cumbersome and inertial. The Internet Computer is a multi-billion dollar computing platform with ambitions to replace much of the global computing infrastructure we know. Effective governance that privileges structure and stability above all is essential to this goal. Currently, the rate of IC development is considerably slower in output than the process described above. The consequence of applying these strictures on the nimbleness of IC development will be negligible. Nevertheless, the next blog post features a framework for proposal development that enables more rapid decision-making for emergencies.

Secondly, this post is a call to arms. Mistakes have been made in IC development and NNS governance, and while we retain the current ad hoc governance style, unnecessary mistakes will continue to be made. Hundreds of millions of dollars have been poured into application development on the IC. Better governance will considerably magnify the output value of that spending. The only way we will see this happen is if teams building on the IC take responsibility for steering the IC in the right direction by sharing their expertise and unique knowledge.

This means either allocating a senior staff member to 10 hours of committee work per week or finding one or more community members to act as representatives. This is skilled knowledge work and all committee members should be appropriately paid by the organisations they represent. Moritz Fuller, Wenzel Bartlett and Kyle Langham are examples of community members who would make excellent delegates (not that I know they have the time).

Thirdly. In my (admittedly limited) experience with standards work it was apparent that ISO committees doubled as a kind of elite industry club. Partnerships were established, knowledge shared, industry-wide strategies developed,  advanced research performed, and intel gathered. This is to say, participation had clear outputs in addition to influencing industry standardization. The same can be expected of the committees described here.

Finally. There is nothing wrong with DFINITY or the developer forum. They are both great at what they do well. What is problematic is the role they play in Internet Computer governance. I advocate for identifying key parts of the IC governance process that need to be in the hands of stakeholders and giving them to those stakeholders.

Connect With Us:

Twitter | Telegram | Instagram | Facebook | Email

• Disclaimer: The views and opinions expressed on this website are solely those of the original author and other contributors. These views and opinions do not necessarily represent those of the Dfinity Community staff and/or any/all contributors to this site.