Introduction

This page is created to provide a framework for the modifications of the proposed Anuket Charter. The baseline document was created by Pankaj Goyal based on current Anuket TSC Operational Guidelines document.

Ways of working

• A copy of the proposed documents added to this page
• Please comment the text in the documents using the inline commenting feature of Confluence in a way that the whole text to be replaced is marked for commenting
• Propose a modified text in your comment if possible
• Once there is a consensus on the text to be modified it will be edited to the text

The proposed document for commenting

Anuket Project Operations and Procedures

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. Project 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 review-ed according to the rules of its sub-project.

2.1.3. Committers

Project Committers

For each project, there is a set of Comitters approved for the right to commit code to the source code management 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.
• Committers are the best available individuals, but usually work on components in active development.

2.1.3.1. Adding Project Committers

The Anuket TSC is responsible for adding Contributors to new or a reactivated moribund project.

• An initial set of up to 3 (three) Project Committers from different organisations will be specified by the Anuket TSC at project creation or reactivation of a moribund project.
• The Committers for a project select and vote for new Committers for that project, subject to TSC approval.
• New Committers for a project should have a demonstrable established history of meritocratic contributions in the technical domain of the project.

2.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-tsc@lists.anuket.io mail 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.
• Only one Committer from an organization can participate in this vote. The Committers from the same organization shall identify one Committer to participate in the vote.
• A 2/3^rd majority of the eligible Committers to vote shall be required for a Committer to be removed.

The PTL shall inform the Anuket TSC of any committers who reign 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.

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:

• 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

2.1.4.1. PTL Election Mechanics

The Anuket TSC shall vote to elect PTLs at the time of the creation of a project, or in the case of a vacancy, or at the end of the PTL term.

• 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 Anuket TSC members (not those voting)
  • 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 (i) ask the current PTL to continue as interim leads for another three (3) months, and (ii) after waiting for 30 days, restart the process starting with the solicitation of candidates.

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

• The project is initially created or reactivated
• The PTL resigns
• First week of December

All members of the Anuket TSC shall be invited to vote in the election of the PTLs. The election shall be administered by Anuket staff and the results shall be communicated to the Anuket community.

2.1.4.2. PTL Term

• The term for a PTL shall end on the first Sunday of January.

2.1.4.3. PTL Candidates

Candidates for PTL:

• may self-nominate or be nominated by any Anuket participant.
• Must demonstrate an advanced level of professional experience in the scope of the project
• are expected to have demonstrable leadership skills
• must commit that they have the available bandwidth to make the time to invest in the success of the project
• must operate neutrally in discussions and put the goals and success of project above any of their employer

2.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
• favours or ignores certain views, opinions, voices, etc.
• is in violation of the LFN Code of Conduct

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 the Anuket TSC Technical Discussions call. If all fails, the issues are escalated to the Anuket TSC for decision.

2.3. Release Process

The Anuket TSC decided on the bi-annual release dates. 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 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

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