3. Project Governance

3.1. Rationale

The governance model is a document that clearly describes how third parties are to engage with the Cherab project and provides the rules and boundaries that ensure that the project remains manageable within the resources available. In this next phase of the Cherab project it makes sense to use an open community led management model, such as the Meritocracy model used by Mozilla, Apache and other large open source projects.

A key reason for setting up an open governance model is to prevent the code from being forked. Forking, or taking the source code and setting up a competing project, is an issue open source projects must be prepared to deal with. If there is disagreement within the community, forking may seem to be the most efficient solution in the early stages of a project. However, this will over time create significant maintenance problems for everyone. There are a number of examples in the fusion community where forking has led to code duplication and a more costly programme.

3.2. Overview

Cherab is a meritocratic, consensus-based community project. Anyone with an interest in the project can join the community, contribute to the project design and participate in the decision making process. This document describes how that participation takes place and how to set about earning merit within the Cherab community. This governance model is based on the Open Meritocracy model used by a number of large open source software projects (e.g. Apache foundation).

Most users will be members of the scientific community, contributing to physics models and diagnostic designs. The scientific strategy for Cherab will be set through the existing management channels, such as the JET Task Force and EUROfusion meetings. The bulk of this document deals with the technical management of the project, to ensure the integrity of the code base is protected and maintained at a high standard. This will be achieved through the use of a Technical Management Committee.

3.3. Roles and responsibilities

3.3.1. Users

Users are community members who have a need for the project. Anyone can be a user; there are no special requirements.

User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user contributions include (but are not limited to):

  • using the project for physics analysis

  • evangelising about the project

  • informing developers of strengths and weaknesses from a new user perspective

3.3.2. Contributors

Contributors are community members who contribute in concrete ways to the project. Anyone can become a contributor. In addition to their actions as users, contributors may also find themselves doing one or more of the following:

  • adding new physics models and features

  • supporting new users

  • reporting bugs

  • identifying requirements

  • providing graphics and web design

  • programming

  • assisting with project infrastructure

  • writing documentation

  • fixing bugs

Contributors engage with the project through the issue tracker and mailing list, or by writing or editing documentation. They submit changes to the project itself via patches, which will be considered for inclusion in the project by existing committers (see next section).

As contributors gain experience and familiarity with the project, they may find themselves being nominated for committership.

3.3.3. Committers

Committers are community members who have shown that they are committed to the continued development of the project through ongoing engagement with the community. Committership allows contributors to more easily carry on with their project related activities by giving them direct access to the project’s resources. That is, they can make changes directly to project outputs, without having to submit changes via patches.

The key difference between a committer and a contributor is when this approval is sought from the community. A committer seeks approval after the contribution is made, rather than before. Seeking approval after making a contribution is known as a commit-then-review process. It is more efficient to allow trusted people to make direct contributions, as the majority of those contributions will be accepted by the project. The project employs various communication mechanisms to ensure that all contributions are reviewed by the community as a whole.

New committers can be nominated by any existing committer. Once they have been nominated, there will be a vote by the Technical Management Committee (TMC; see below) to approve their membership.

3.3.4. Technical Management Committee (TMC)

The TMC is the technical decision making body and acts as stewards of the project. The main role of the TMC members is to review code contributions and participate in technical strategic planning. It also makes decisions when community consensus cannot be reached.

Membership of the TMC is by invitation from the existing TMC members. A nomination will result in a vote by the existing TMC members, requiring consensus approval.

3.3.5. TMC Chair

The TMC Chair is a single individual, voted for by the TMC members. Once someone has been appointed Chair, they remain in that role until they choose to retire, or the TMC casts a two-thirds majority vote to remove them. The TMC Chair has no additional authority over other members of the TMC: the role is one of coordinator and facilitator. The Chair is also expected to ensure that all governance processes are adhered to, and has the casting vote when the project fails to reach consensus.

3.4. Decision making process

Decisions about the future of the project are made through discussion with all members of the community. In order to ensure that the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote.

3.4.1. Lazy consensus

Decision making typically involves the following steps: - Proposal - Discussion - Vote (if consensus is not reached through discussion) - Decision

Any community member can make a proposal for consideration by the community. In order to initiate a discussion about a new idea for a physics model or diagnostic they should raise their idea through the usual scientific channels (e.g. EUROfusion task force meetings). They can then submit a patch implementing the idea to the issue tracker (or version-control system if they have commit access). This will prompt a review and, if necessary, a discussion of the idea. The goal of this review and discussion is to gain approval for the contribution. Since most people in the project community have a shared vision, there is often little need for discussion in order to reach consensus.

In general, as long as nobody explicitly opposes a proposal or patch, it is recognised as having the support of the community. This is called lazy consensus - that is, those who have not stated their opinion explicitly have implicitly agreed to the implementation of the proposal.

3.4.2. Voting

Not all decisions can be made using lazy consensus. Issues such as those affecting the core architecture of the project must gain explicit approval in the form of a vote. Every member of the community is encouraged to express their opinions in all discussion and all votes. However, only TMC members have binding votes for the purposes of technical decision making.