This is a draft version for approval. The last approved version is v6 here: Anuket Project Operations and Procedures

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. Community election procedure

Community election procedure is described here: Community Election Procedure

3. 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.  

3.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.

3.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).

3.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.

3.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.

• Committer rights are per project; being a Committer on one project does not give an individual committer rights on any other project.
• The Committers will be the decision makers on all matters for a project including design, code, patches, and releases for a project.
• Once the project passed the Creation Review its committers have a sustained record of contributions to the project.

3.1.3.1. Adding Project Committers

• The Committers for a project select and vote for new Committers for that project.

3.1.3.2. Removing Committer

A Committer may voluntarily resign from a project by making a request to the project team lead (PTL) to resign (via anuket-tech-discuss@lists.anuket.io 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 be responsible for organizing the vote of the project’s Committers for the removal of a Committer.
• The Committers from the same organization shall identify one Committer to participate in the vote.
• A 2/3^rd majority of the project Committers shall be required for a Committer to be removed.

The PTL shall inform the Anuket TSC of any committers who resign or are removed, including the reason for removal, via the anuket-tsc@lists.anuket.io 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.

• If the PTL or any Committer for that project is a voting member of the Anuket TSC then they shall recuse themselves from voting in the Anuket TSC.
• A simple majority of the Anuket TSC members in attendance, if there is a quorum, is required to overturn the decision of the project’s Committers.

3.1.4 Documentation volunteers

To guarantee that the look and feel of the project documentation is consistent the TSC can appoint documentation volunteers, these volunteers are responsible to keeping the project documentation in consistent look and feel across all the sub-projects and repos of the project. The appointed documentation volunteers get committer rights to all repos of the project. Documentation committers can ask an approval from the TSC to override branch protecting rules and merge documentation related changes. The TSC must approve every branch protection rule override.

3.1.4. Project Technical Leader

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

• steering the work towards a successful conclusion
• ensuring that the work benefits from a wide spectrum of views
• ensuring a consensus-based approach, as much as is possible, in achieving decision
• organizing and conducting meetings with the objective of furthering the project objectives
• ensuring quality of deliverables

3.1.4.1. PTL Election Procedures

General:

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

• An invitation to the sub-project active membership shall be sent for nominations.
• A candidate may be nominated or may self-nominate.
• The election shall be administered electronically by the sub-project and the results shall be communicated to the Anuket TSC for ratification. The TSC ratification shall be pro-forma exercise.
• If there is only one candidate for a position, then the person is elected to the position by default.
• To be elected to the position requires a simple majority of the eligible voting members
• In case no candidate secures a majority (see clause above),
  • if the election was contested by more than two (2) candidates, another vote shall be conducted amongst the two candidates to get the highest number of votes
  • if the election was contested by only 2 candidates and after the election none of the two withdraws/concedes in favour of the other candidate, then the TSC shall be asked to appoint an interim PTL as per "Interim PTL appointment" below and after a 30 day waiting period, initiate the process for PTL election.

Eligible Voting Members:

The eligible voting members shall be:

• If an election is held in the TSC then the entire TSC membership not only those present at a meeting.
• If the election is held by project then the eligible voters shall be the:
  • Active contributors of specfication type projects and committers of other type projects to the project

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

3.1.4.2. PTL Term

• The term for a PTL shall follow the term of the TSC, therefore should end on the first Saturday of January.

3.1.4.3. PTL Candidates

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

3.1.4.4. PTL removal

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

• is absent without notification to the TSC and the project for more than 2 weeks
• has been ignoring their responsibilities including not holding a project meeting for more than 4 weeks
• TSC determines that the PTL is in violation of the LFN Code of Conduct

3.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.

3.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

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.

• Longevity of the sub-project
• Sub-project follows Anuket release cadence
• Requirements have resulted in corresponding realizations
  • Comprehensiveness and maturity of the artifacts (code, test cases, documentation) the sub-project produces including contributions/code to partner/upstream sub-projects where applicable
  • Mature testing/integration success for defined environments (Anuket and/or partner/upstream sub-projects, which is applicable or both) when applicable
  • Completeness of the specifications and documentation for specification type sub-projects
• Community
  • Size and diversity of the active community (number and diversity of people contributing)

Creation Review

• Proposal posted for two weeks:
  • Name of the sub-project is appropriate (no trademark issues etc.); Proposed repository name is all lower-case without any special characters
  • Sub-project contact name and email
  • Description is complete
  • Scope and sub-project plan is well defined
  • Reference of an existing NFV requirement or clear identification of a new requirement
  • Resources committed
  • At least three (3) contributors from different organisations identified
  • Initial list of committer identified (elected/proposed by initial contributors)
  • Meets Board of Directors (BoD) policy (e.g.: IPR)
  • Proposal has been socialized with potentially interested or affected sub-projects and/or parties
  • In the case where a sub-project will require changes in other sub-projects, those sub-projects are listed in the proposal, and a sponsoring developer in the sub-project has been identified
  • Proposal email to TSC mailing list
• Review by TSC: Confirm that the proposal is complete and the above listed requirements are met.
• Simple majority approval by voting TSC members

Maturity Review

• Graduation to mature state proposal posted for two weeks
• Review metrics for maturity review:
  • Successful participation in releases: The sub-project demonstrates stable output (code base, documents or specifications) within its history of releases in accordance with the release policy.
  • Sub-project is active and contributes to Anuket: The sub-project demonstrates a stable or increasing number of contributions across recent release cycles. Contributions are commits which got merged to a repository of an Anuket sub-project or a related upstream sub-project. Commits can for example be patches to update the requirements document of a sub-project, code addition to an Anuket or upstream sub-project repository, new test cases and so forth.
  • Mature artifacts produced: The sub-project demonstrates that the artifacts produced by the sub-project are deployable (where applicable) and have been successfully deployed and/or used by users.
• TSC review and simple majority approval by voting TSC members for graduation to the mature state

Termination Review

• Termination proposal posted for two weeks
  • A termination review is initiated by the sub-project PTL, unless the PTL is unresponsive to attempts to contact them, or if the sub-project has not submitted an intent-to-participate notification for the two most recent releases. In that case, a sub-project contributor, a TSC member, or LF staff may initiate the termination review. If the termination review is initiated by someone other than the PTL, then the PTL should be copied, using their last known good email address, when the termination review is posted to the mailing list.
• States reason for sub-project termination being sought
• Termination proposal to include acceptable triggers for termination (e.g. protracted idleness, or request by the sub-project)
• Estimates impact on other sub-projects and how to mitigate
• Removal will not break Reference Platform builds
• Location identified and links created for archived sub-project
• Simple majority approval by voting TSC members
• If no approval, remains in pre-reviewed state

Reactivation Review

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

• Proposal posted for two weeks to the TSC mailing list:
  • Sub-project contact name and email
  • Identify any changes to the scope of the original sub-project proposal.
  • Justify reactivating the sub-project, including discussing why the sub-project was terminated and what has changed.
  • Explain what the sub-project intends to accomplish if it is reactivated.
  • Resources committed
  • Contributors identified
  • Initial list of committer identified (elected/proposed by initial contributors)
  • Meets Board of Directors (BoD) policy (e.g.: IPR)
  • Proposal has been socialized with potentially interested or affected sub-projects and/or parties
  • In the case where a sub-project will require changes in other sub-projects, those sub-projects are listed in the proposal, and a sponsoring developer in the sub-project has been identified
• Review by TSC: Confirm that the proposal is complete and the above listed requirements are met.
• Simple majority approval by voting TSC members

3.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:

• Initial Planning: set of high-level deliverables
• Release review: QA of the deliverables
• Publish

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

• Release Deliverables
• Release Milestones
• Expected Dependencies on other sub-projects
• Compatibility with Previous Release
• Themes and Priorities
• Features delivered
• Open Issues (if any)
• Quality Assurance (test coverage, etc.)
• End-of-Support/End-of-life (EOS/EOL) API/Features
• Summary of Outstanding Bugs
• Summary of Standards Compliance
• Delta between planed schedule and actual schedule
• Other

4. 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/3^rd) vote of the entire TSC members.