ICRC-0: Internet Computer Working Group Operation and Governance

| Status | |:---------:| | Draft |

Introduction

The work on the Internet Computer blockchain is a major joint effort by both the IC community and the DFINITY Foundation. The longer-term goal is to ever increase the involvement of the community in developing the Internet Computer technology in the future. A strong community involvement is crucial for multiple reasons, e.g., to address the requirements of a broad selection of IC stakeholders, particularly the active community members, and to have an increasingly decentralized approach to technology development.

The Internet Computer being a truly global project, the IC's stakeholders are distributed throughout the globe. This requires the collaboration to be virtual, to span all time zones, and to still be effective in terms of jointly developing standards and finding agreements. A crucial part of the technology development will take place in technical working groups (TWGs), typically involving stakeholders from both the wider community and DFINITY.

This document proposes an approach to the governance of and collaboration in Internet Computer (technical) working groups. The proposal provides a blueprint for how technical working groups can be set up and operate in terms of developing solutions that fulfill the stakeholders' needs as well as allow for finding agreement so that the stakeholders' interests can be aligned at large. The approach is applicable to any WG in the IC community, but at first is targeted at the Ledger and Tokenization working group, from which it has originated.

The proposed approach of IC WGs has borrowed some of its core ideas from the Internet Engineering Task Force (IETF). The IETF comprises, similar to the IC's WGs, volunteers that help drive the technology forward. IETF working groups, at the core of their working and decision making, use an informal approach based on rough consensus which attempts to find as-wide-as-possible consensus among the stakeholders in a working group. In a nutshell, rough consensus means that most of the eligible people are in agreement on an issue and remaining objections have been discussed and motivated why they have not been accommodated. The people not in consensus are "in the rough" part of consensus.

Due to the similarities between IETF and the IC community in terms of being volunteer communities that want to jointly develop great technology that moves the world forward, we conjecture that rough consensus can work equally well for the IC's working groups.

We next give more details on how working groups are structured in terms of members, the communication and collaboration approach and tooling used, and the consensus finding and decision making.

Composition of a WG

An IC technical working group can be joined by anyone interested in participating in the discussions and joint development of the technology the WG addresses or just following the discussions. A subset of the members of the WG, the core WG team members will be most actively involved in the work, the remaining participating members will rather listen to discussions and occasionally make contributions.

• Core WG team members: The core team of the WG actively participates in the work of the WG and in developing the corresponding technology. The core team needs to be in agreement on the technical issues. The core team attempts to reach rough consensus as explained below and is eligible to vote in the WG, such as on new standard proposals.
• Participating members: Anyone besides the core team is a participating member of the WG and can join the meetings and discussions on all channels. Participating members may express their opinions and are welcome to contribute to the work, however, they are not expected to make substantial contributions and are not part of the decision making of the WG.
• Chair: Each WG appoints at least one chair, ideally two co-chairs, who are responsible for driving the WG, scheduling meetings, and orchestrating the processes of the WG. The chair is also responsible for determining whether the group is in rough consensus on a topic.

Finding the core team of a new WG to be established is an informal process that will quickly converge to an initial core team. The founding members or proposers of the WG will typically be part of the core team, quickly attracting further interested community members early on who are willing to contribute. The core team will evolve over time with members joining and leaving, as the working group progresses. Participants of the core team who do not make major contributions to the WG any more should remove themselves from or be removed from the group.

The members of the core team and the co-chairs of the WG should be agreed on by the WG in the spirit of WG decision making.

Subgroups

A subgroup may form in a WG to address specific topics which not all members are interested in. The subgroup would then convene separately and work to produce its envisioned results. It can use the same governance structures and principles of the WG applied to the subgroup to find agreement within the subgroup. Once a subgroup has arrived at a result with sufficient agreement, it presents it to the full WG. The full WG should strive to have rough consensus. Voting on the results of the subgroup is done in the full WG. A subgroup dissolves itself once its goal, which can be the production of a single result or a series of results, has been achieved.

Collaboration and communication

As the team members are distributed globally throughout all time zones and there are typically no physical face-to-face meetings of the WG, the methodology for collaboration needs to fully embrace an approach for efficient and effective virtual collaboration. IC WGs use multiple, but a small number of, communication channels and tools to collaborate. Both synchronous and asynchronous collaboration should be facilitated to allow for efficient progress of the technical work, resolving comments and objections by members, and converging to a broadly-accepted view among the core members, ultimately achieving rough consensus on an item.

For a distributed group like the IC community it is crucial to have a WG setup that can include also the people in the discussion that cannot attend the regular virtual WG meetings, e.g., due to time zone constraints.

IC WGs will typically use a subset of the collaboration tools mentioned below. The idea is to have as few tools as possible to avoid overhead for members (and the chairs). The concrete choice of tools is left to the discretion of the WG. As recommendation, more technical- and coding-affine WGs should use Zoom, the Forum, Discord, and GitHub, while less technical-affine groups might want to replace GitHub with GoogleDocs for the drafting of and commenting on their working documents. The governance processes are in principle tool agnostic, however, we provide some discussion and recommendations on tools here to allow for faster bootstrapping of a new WG and to help the WG avoid reinvent the wheel w.r.t. tooling.

• GitHub as asynchronous collaboration tool: working on documents and code; discussions of PRs; commenting on and objecting to specific issues of proposals; determining rough consensus through humming; formal voting
• Google Docs as asynchronous collaboration tool: document authoring; commenting; making objections; discussing
• Virtual meetings in Zoom as synchronous collaboration tool: technical discussions, continuing discussions from GitHub in a synchronous setting; discussion of strategic topics such as new work items, spawning a new working group; resolving issues
• IC developer forum as asynchronous communication channel: updates to the working group; announcements; technical discussions that do not fit into specific items on GitHub or Google Docs; strategic and roadmap discussions
• Discord as a communication tool with similar usage as the forum and in addition synchronous chats.

The Ledger and Tokenization WG uses the following tools:

• Zoom
• GitHub
• Forum
• Discord

Zoom teleconferencing

Regular (typically weekly or bi-weekly 1-hour) virtual video conference meetings provide a platform for synchronous collaboration of the team. These meetings are the periodic integration points of discussions held on other channels, where team members can engage in a realtime discourse on the currently handled topics of the WG, as well as strategic and roadmap topics. The meeting cadence and schedule can be changed at the discretion of the WG, e.g., to align with the current workload or timeline requirements.

Particularly, the meetings are used, among other things, for the following:

• Discussing individual items the group is currently working on: A main part of the meetings is dedicated to addressing comments and objections on standards proposals in the spirit of rough consensus. This continues discussions on GitHub and uses the power of synchronous interactions between the participants.
• Elaborating the strategic roadmap of the WG: For example, discussing the direction, future work items, new WGs or subgroups to be created for specific topics.
• Discussing upcoming work items.
• Virtual humming to assess the degree of consensus in the group.

WG meetings should have minutes published on GitHub that summarize the discussions and main decisions taken in the meeting. This helps transparency for everyone and individuals outside the WG as well as participants who cannot participate in a meeting to catch up with the progress of the WG.

Due to the IC community's global presence, at least one of the geographies may not be conveniently able to participate during a given time slot. The WG can either choose a fixed time slot and involve the team members from non-participating geographies via other channels, or rotate the time slot so that all parts of the world can p