This is the Anuket Project Operations and Procedures document. The document was agreed on the 2021-11-02 TSC meeting.

Changes should be suggested as inline comments and have to be agreed in the TSC.

1. Structure of the Technical Community

The Anuket Technical Community consists of multiple sub-projects and a Technical Steering Committee (TSC) that oversees all sub-projects.

2. Sub-project Management

The Anuket Project will at any given time consist of a set of sub-projects.

A sub-project is created by the Anuket TSC as a development or specification (e.g., code, Reference Model or Reference Architectures) work item, and has a defined scope beginning, end and resources. In this document, Anuket Project will be used for the LFN project while, hereafter, project, without the qualifier Anuket, will be used to refer to a sub-project.  

2.1. Roles

The success of a project shall require several active participants drawn from a variety of organisations. Participants can have specific roles on the project.

2.1.1. Contributor

A Contributor is someone who contributes to a project. Contributions can take the form of requirements, specifications, code, or other artifacts (collectively hereafter artifacts).

2.1.2. Reviewers

For each project, Reviewers review, ask for changes and approve the artifacts. Anyone can review, comment and approve the artifacts.

An artifact is considered to have been “Approved” if the artifact has been reviewed according to the rules of its sub-project.

2.1.3. Committers

For each project, there is a set of Committers approved for the right to commit to the version control system (the “Committers”) for that project. Adding Project Committers Removing Committer

A Committer may voluntarily resign from a project by making a request to the project team lead (PTL) to resign (via mailing list).

A Committer for a project who is disruptive or has been inactive on that project for at least six months may have their Committer status revoked by a vote of the project’s committers.

The PTL shall inform the Anuket TSC of any committers who resign or are removed, including the reason for removal, via the mail list.

A Committer voted to be removed for cause shall have the right to petition the Anuket TSC to reject their removal. In case of such a petition, the Anuket TSC shall vote on accepting or rejecting the removal. The Anuket TSC may invite the PTL and the aggrieved person to oppose/defend the decision.

2.1.4. Project Technical Leader

The project PTL are the leaders and de facto spokesperson for the project. As leaders, PTLs are responsible for: PTL Election Procedures


In case of a vacancy for a PTL position or two weeks prior to the end of the term of the current position holder:

Eligible Voting Members:

The eligible voting members shall be:

Interim PTL Appointment

In the case where an election of the eligible voters ends up in a tie then the TSC shall appoint an Interim PTL until new elections can be held:

(i) ask the current PTL to continue as interim lead for a period of three (3) months, or
(ii) if (i) is not feasible then elect one of the TSC members to be the interim PTL

PTL Appointment

The Anuket TSC shall appoint PTL at the time of the creation of a sub-project, or at time of reactivation of a archived sub-project. The TSC shall also appoint an interim PTL in the case where the sub-project active contributors are unable to elect a PTL.

An election for Project Technical Leader shall occur when any of the following are true:

  1. The sub-project is initially created or reactivated;
  2. The PTL resigns; the active contributors of that sub-project shall elect
  3. First week of November (for next year); the active contributors of that sub-project shall elect PTL Term PTL Candidates

Candidates for PTL may self-nominate or be nominated by any Anuket participant. PTL removal

A PTL can be removed by a 2/3rd vote of all TSC members if the TSC has received reports that the PTL:

2.2. Decision Making Process

Project technical and release decisions shall be made by consensus of the Reviewers and Committers of that project participating in meetings organized for that purpose. If consensus cannot be reached, the issues are escalated for discussion at a public forum available for Anuket project participants (e.g.: Anuket mailing lists, chat channels or the Anuket Weekly Technical Meetings). If all fails, the issues are escalated to the Anuket TSC for decision.

2.3. Sub-project lifecycle

The activities of the Community are organized into sub-projects targeting different areas within the scope of Anuket.  These sub-projects might fall into several categories, specification and requirements documentation, code or testing functions.  The lifecycle of each of these types of sub-projects will vary depending on the nature of the sub-project.  These sub-project might include, but not be limited to requirements gathering, and specification documentation, development of upstream code, integration of platform components, support functions to create and maintain the infrastructure and the development and maintenance of the toolchains.

Lifecycle overview
Anuket defines three maturity levels that each sub-project goes through during its lifecycle. The procedure of moving from one level to the next one is independent from the release process of Anuket and the pace depends on each individual sub-project.

The lifecycle of the sub-projects is depicted on the following diagrams:

Source of the figure: Sub-project lifecycle v1.pptx

Sub-project States

Sub-project stateDescription
ProposalSub-project doesn’t really exist yet, may not have real resources, but is proposed and is expected to be created due to needs.
IncubationSub-project has resources and it in the process of being developed, but does not have enough artifacts or features to be functional or be in line with the Anuket releases in a stable manner.
MatureSub-project is fully realized and stable, might have on-going releases with new features or specifications over time.
ArchivedSub-project has been recognized as dead (could be for a variety of reasons, e.g. sub-project successfully accomplished its goals, sub-project failed, etc.), and has been archived as it is no longer an on-going sub-project.

Reviews & Metrics

Sub-project promotion, and demotion, across states can only be done by TSC review and voting. During the reviews the candidate sub-projects are evaluated based on predefined metrics and KPIs. The target numbers may vary for the different levels and nature of the sub-project type.

Creation Review

Maturity Review

Termination Review

Reactivation Review

A sub-project that was previously approved by the Anuket TSC, then later terminated, may be reactivated, as follows:

2.4. Release Process

The Anuket TSC decides on the bi-annual release dates and the entire release cadence and calendar for the release process. Sub-projects shall publish a Release Plan at the beginning of a release cycle. The Release Plan shall have certain common tasks whose duration shall be fixed by the Anuket TSC:

Other elements of the Release Plan may contain the following sections:

3. Amendments

Amendments to this Anuket Project Operations and Procedures document can only be made by a majority vote of all TSC members, except that changes to any voting mechanism and requirements shall require a two-thirds (2/3rd) vote of the entire TSC members.