...

The Akraino Edge Stack technical project has been established as Akraino Project a Series of LF Projects, LLC (“Akraino Edge Stack” or, alternatively, the “Project”).  LF Projects, LLC is a Delaware series limited liability company.  Governance for the Project is detailed within the Project Technical Charter available at akraino.org (“Technical Charter”).  This Technical Community Document is intended to provide additional operational guidelines for the Project, and is subject to the Technical Charter.  “Akraino” is the term used in this document that refers to ”Akraino Edge Stack” (full form).  

1    Guiding 1   Guiding Principles 

The Akraino Edge Stack Project a Series of LF Projects, LLC (“Akraino”) will operate transparently, openly, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders.

2    2   Structure of the Technical Community

The Technical Community consists of multiple projects and a Technical Steering Committee that spans across all projects.

2.1 Technical 1   Technical Mission of Akraino Edge Stack

...

Figure 2 - Sector 2: Enterprise and Industrial IoT use cases

3    Per 3   Per Project

3.1  Project  Project Roles 

3.1.1   Contributor

...

In order to preserve meritocracy in selection of Committers while ensuring diversity of Committers, each initial project is encouraged to take on at least two Committers from different companies (subject to meritocracy).

3.1.3   Project Technical Leader

...

A project is required to elect a Project Technical Leader (“PTL”). The PTL acts as the de facto spokesperson for the project (feature projects and integration projects). 

3.1.3.1 Project 1   Project Technical Leader Candidates

...

Candidates must self nominate.

3.1.3.2 Project 2   Project Technical Leader Voters

Only Committers for a project are eligible to vote for a project’s Project Technical Lead.

3.1.3.3 Project 3   Project Technical Leader Election Mechanics

...

• The project is initially created
• The Project Technical Leader resigns his or her post
• The majority of committers on a project vote to call a new election
• One year has passed since the last Project Technical Leader election for that project

3.2  Project  Project Operations

3.2.1   Project Decisions Making Process

Technical and release decisions for a project should be made by consensus of that project’s Committers.  If consensus cannot be reached, decisions are taken by majority vote of a project’s Committers.  Committers may, by majority vote, delegate (or revoke delegation) of any portion of such decisions to an alternate open, documented (wiki), and traceable decision making process.

3.2.2   Committer 2   Committer Lifecycle

3.2.2.1 Adding 1   Adding Committers

• Initial Committers for a project will be specified at project creation 
• Committer rights for a project are earned via contribution and community trust. Committers for a project select and vote for new Committers for that project.
• New Committers for a project should have a demonstrable established history of meritocratic contributions.

3.2.2.2     Adding 2   Adding Committers to moribund projects

...

The method by which the TSC appoints an interim Committer is first by request to the Akraino-TSC email list indicating the request to appoint an interim Committer for a project.  After the reception of such an email, the normal TSC decision process applies.

3.2.2.3     Removing 3   Removing Committers

A Committer may voluntarily resign from a project by making a public request to the PTL to resign (via the project email list and cc to tsc@lists.akraino.org ).

...

Former committers removed for reasons other than being disruptive may be listed as ‘Emeritus Committers’.  That title expresses gratitude for their service, but conveys none of the privileges of being a Committer.

3.3  Project  Project Lifecycle

3.3.1   Akraino Project Lifecycle

...

Figure 3 – Akraino Edge Stack Project Types & Scope

3.3.2.1 Akraino 1   Akraino Edge Stack Feature Projects  (a.k.a Development Project)

...

Figure 4 – Relationship between Feature Project, Upstream component and Integration project

3.3.2.2 Akraino 2   Akraino Edge Stack Integration Projects (Blueprints)

...

Figure 5 – Akraino Blueprint Creation Process

3.3.2.2.1 Akraino 1   Akraino Blueprint Family and Life Cycle of Blueprints

...

Figure 6 - Illustration of blueprint family and its blueprints

3.3.2.2.2 Akraino 2   Akraino Use Cases, blueprint families and blueprints

...

Below are the sample templates of a target family of blueprints and the full template will be maintained on the wiki. Certain attributes shall be defined as informational only. For example cost targets whilst key should not be used to pass or fail the verification of a blueprint

3.3.2.2.2.1   Template 1 Template 1 - Use case template

Below is a sample Use case template. The full template will be maintained on the Akraino Wiki.

 3.3.2.2.2.2 Template 2   Template 2 - Blueprint family template

...

 3.3.2.2.2.3 Template 3   Template 3 - Blueprint species template

...

3.3.2.3 Akraino 3   Akraino Validation Projects

Multiple labs will be used to validate Akraino projects to ensure production quality of blueprint and/or feature project releases. The Community CI lab is owned by the Akraino community and LF. In addition a number of Edge FLock labs are owned by an Akraino community company, organization or participant.

...

The TSC subcommittees tasked with the setup and structuring of operating procedures for the validation labs shall work to define the licensing requirements for the external labs.

3.3.2.3.1 Feature 1   Feature project unit testing in Community CI lab

...

 A full CD that works with the Akraino CI pipeline should be included in the validation project.

3.2.2.3.2  Blueprint  Blueprint and application testing in Akraino Edge Flock lab

...

3.3.7   Project Reviews

3.3.7.1     Incubation 1   Incubation Review

The goal of the Incubation Review is to officially launch the project and to support its needs until project Termination Review.

...

• Name of the project is appropriate (no trademark issues etc.); Proposed repository name is all lower-case without any special characters
• Project contact name, company and email are defined and documented
• Description of the project goal and its purpose are defined
• Scope and project plan are well defined
• Resources committed and available
• Contributors identified
• Initial list of committers identified (elected/proposed by initial contributors)
• Meets Akraino TSC Policies
• Proposal has been socialized with potentially interested or affected projects and/or parties
• Cross Project Dependencies (XPDs). In the case where a project will require changes in other projects, those projects are listed in the proposal, and a sponsoring developer in the project has been identified
• Tools have been identified and discussed with relevant partners (Linux Foundation, IT). Once the project passes the review, the tools chain must be created within one week. Tools encompass Configuration Management, CI/CD, Code Review, Testing, Team Wiki, End Users documentation (not exhaustive)

3.3.7.2     Maturity 2   Maturity Review

The goal of the Maturity Review is to ensure:

...

• Successful participation in releases: The project demonstrates stable output (code base, documents) within its history of releases in accordance with the release policy.
• Architecture has been reviewed by the Architecture Committee
• Project is active and contributes to Akraino: The project demonstrates a stable or increasing number of contributions across recent releases. Contributions are commits which got merged to a repository of an Akraino project or a related upstream project. Commits can for example be patches to update the requirements document of a project, code addition to an Akraino or upstream project repository, new test cases and so forth.
• Mature artifacts produced: The project demonstrates that the artifacts produced by the project are deployable (where applicable) and have been successfully deployed, configured and used by end users (typically, service providers).

3.3.7.3     Core 3   Core Review

The goal of the Core Review is to ensure:

...

• Contributor diversity: The project demonstrates that it has a stable core team of contributors/committers which are affiliated to a set of at least three different companies. Core team members are those who have been active on the project for more than two releases, which means they were reviewing contributions to the project in Akraino Code Review and/or in the review-tool of the target upstream project(s).
• Recognized value through other projects: The project demonstrates that its results are leveraged by other Akraino projects in an ongoing way, i.e. for at least the last two releases.
• Successful integration tests (only applicable to projects which provide features/functionality): The project demonstrates that component tests and system-level tests have been implemented, that tests are used within the Akraino CI/CD test pipeline, and that tests bear successful results.
• Stability, Security, Scalability and Performance levels have reached a high bar.

3.3.7.4     Termination 4   Termination Review

The goal of the Termination Review is to ensure that:

• Artifacts for Core state are complete and accepted
• Core project artifacts are acceptable and meet the acceptance criteria
• Project Team has the confidence that its artifacts can be used outside the Akraino community
• Metrics for Termination review are available

3.3.8   Mature 8   Mature Release Process

A Project’s Committers make all decisions about Releases of that Project.  However, to be eligible to be considered ‘Mature’, the project must demonstrate a history of following the Mature Release Process.  The purpose of the Mature Release Process is to insure openness and maximum opportunity for participation.  The idea is to have a simple, clear, public declaration of what a project intends to do and when, and what was actually done in a release cycle.   Towards that end, a project following the ‘Mature Release Process’ should have a Release Plan published at the beginning of its release cycle by its committers, and a Release Review just prior to the project release.

...

These should contain roughly the following sections:

  33.3.8.1  Release  Release Plan

• Introduction
• Release Deliverables
• Release Milestones
• Expected Dependencies on Other Projects
• Compatibility with Previous Release
• Themes and Priorities
• Features delivered
• Non-Code Aspects (user docs, examples, tutorials, articles)
• Architectural Issues (if any)
• Security Issues (if any)
• Quality Assurance (test coverage, etc)
• End-of-life (API/Features EOLed in Release)
• Summary of Outstanding Bugs
• Summary of Standards Compliance
• Delta between planned schedule and actual schedule
• Features delivered
• Non-Code Aspects (user docs, examples, tutorials, articles)
• Architectural Issues (if any)
• Security Issues (if any)
• Quality Assurance (test coverage, etc)
• End-of-life (API/Features EOLed in Release)
• Summary of Outstanding Bugs
• Summary of Standards Compliance
• Delta between planned schedule and actual schedule

3.3.8.2     Release 2   Release Review

3.4  Amendments  Amendments to the Technical Community Document

The TSC may make amendments to this Technical Community Document at any time with a simple majority of the members of a quorum of the TSC as defined in section 4.4.1.

4    Technical 4   Technical Steering Committee

4.1  Akraino  Akraino Community Active Contributors

...

At the transition time the qualification period will be from the point of project inception to the transition date.

4.2  TSC  TSC Members

TSC Members consist of an elected subset of up to 20 people from the community’s Active Contributors.

...

Figure 10 - Akraino Community Structure

4.3 TSC 3   TSC Functional Roles

In addition to Active Contributors and TSC Members there are other roles within the community such as TSC Chair, TSC Co-Chair, Coordinators, project specific committers and others.

Community members with functional roles are not TSC  members in their own right.

4.3.1 TSC 1   TSC Chair and Co-Chair

The TSC Chair and Co-Chair are elected by the TSC members.

...

The Chair and Co-Chair work together to share the responsibilities of chairing the TSC.

4.3.1.1 Responsibilities1   Responsibilities

The primary responsibility of the TSC Chair and Co-Chair are to represent the technical community in communications with the LF Akraino Edge Stack Fund of The Linux Foundation and to be responsible for:

• Leading TSC meetings;

• This responsibility may be delegated to another TSC Member  (in such case, this is to be informed via the TSC email list)

• Representing the technical community to external organizations.

• These responsibilities may be delegated to another member of the technical community.

• Lead the TSC in the execution of the TSCs responsibilities (section 4.3).

4.3.3 Coordinators3   Coordinators

4.3.3.1     Coordinator 1   Coordinator Description

Coordinators are not members of the TSC per se. However a Coordinator may also be a member of the TSC in their own right as an elected Active Contributor.

...

Coordinators support the TSC Chair in the execution of TSC responsibilities (Section 4.5) and the delivery of Akraino releases. They are responsible for fostering collaboration among the many parties that need to work together to identify, characterize, and solve problems, they do not direct solutions.

4.3.3.2     Coordinator 2   Coordinator origin.

The TSC will solicit nominations for the role. Nominees should have subject matter experience in the relevant coordination area. In the event that multiple candidates self-nominate, the TSC will hold an election as defined in section 4.4.3.3.

The coordinator will regularly report status and issues to the TSC via the Akraino-TSC email list.

4.3.3.3     Coordinator 3   Coordinator and coordination area lifecycle

...

The decision to close the coordination area is created by a TSC decision (according to the TSC voting rules).  Once a coordination area is updated, the coordination area will be removed from the Akraino Wiki.

4.4  TSC  TSC Operations

4.4.1   TSC 1   TSC Decision Making Process

At the transition point and until changed by the TSC there shall be up to 20 seats on the TSC including the chair and co-chair.

...

4.4.2   TSC Election Candidate and Voter Eligibility

4.4.2.1 TSC 1   TSC Members

There are no limitations on the number of candidates that can run in an election for TSC membership, nor is there a limit to the number of candidates from any organization including its subsidiaries (hereon termed simply an ‘organization’)  that can run for TSC membership. However the limits as defined in the TSC technical charter for the total number of TSC members from a given organization shall be enforced  by means of the election and interim election process described in 4.4.3

Candidates must self nominate.

4.4.2.1.1 Candidate 1   Candidate and Voter Eligibility

Any Active Contributor community member is eligible to run for TSC membership

...

Eligibility is effective as of the date and time the nomination process starts

4.4.2.2 TSC 2   TSC Chair and Co-Chair functional roles

...

Candidates must self nominate.

4.4.2.2.1 Candidate 1   Candidate and Voter Eligibility

All TSC members are eligible to run for the roles of Chair or Co-Chair.

...

All TSC Members are eligible to vote in a TSC Chair and Co-Chair election.

4.4.2.3 TSC 3   TSC Coordinators functional roles

...

Candidates must self nominate (even if nominated by the TSC).    

4.4.2.3.1 Candidate 1   Candidate and Voter Eligibility

Any community member (regardless of TSC membership) is eligible to serve as a coordinator.  Nominees should have subject matter experience in the relevant coordination area.

...

4.4.3   TSC Election Mechanics

4.4.3.1 TSC 1   TSC Member Elections

All TSC members shall be elected at the Transition Point and subsequently every year within one month of the yearly anniversary of the date of the Transition Time.

4.2.3.2  TSC  TSC Member Election Mechanics

...

All TSC Active Contributors may cast a single vote

4.4.3.2.1 Enforcement 1   Enforcement of organization TSC member limits.

...

Once this is done the remaining 20 highest ranked candidates shall be elected to the TSC.

4.4.3.2.2 Interim 2   Interim elections

In case a TSC member, including Chair or Co-Chair, steps down or is required to step down due to organization limits being exceeded or as a result of company acquisitions or mergers after each yearly election, an interim election may be called by the TSC.

...

Interim elections shall otherwise follow all the same procedures and use the same voting schemes as the yearly elections.

4.4.3.3     TSC 3   TSC Chair/Co-Chair/Coordinator Election Mechanics

...

Election of a TSC Chair/Vice Chair/Coordinator shall use a multiple-candidate method shall consist of a single stack ranked vote of all candidates using  CIVS  https://civs.cs.cornell.edu/

4.5 

...

 Responsibilities of the TSC

...

Subject to the Technical Charter, the TSC is responsible for:

• Defining Akraino’s release vehicles (such as a Coordinated Release) that align with the Project’s,mission,
• Fostering cross-project collaboration,
• Serving as Akraino’s primary technical liaison body with other consortiums and groups,
• developing an architecture,
• setting simultaneous release dates,
• defining release quality standards,
• defining technical best practices and community norms (including the establishment and maintenance of a Development Process),
• monitoring technical progress,
• mediating technical conflicts between Committers and PTLs,
• organizing inter-project collaboration,
• coordinating technical community engagement with the end-user community.

4.6  TSC  TSC Subcommittees

The TSC, at its discretion, may establish subcommittees to assist the TSC with its responsibilities and provide expert guidance in technical subject areas (e.g., architecture or security).

The TSC may amend or introduce alternative approaches to convene and run subcommittees.

4.6.1   Membership

4.6.1.1 Subcommittee 1   Subcommittee Membership Eligibility

It is expected that subcommittee membership shall be open to all Akraino Contributors; however, subcommittees [or TSC] may impose restrictions such as the number of participants from a single company [organization]. While the desire may be to keep its size and scope limited, each subcommittee shall be open to the Akraino membership. 

...

Each subcommittee may elect a Chair and optionally a Co-Chair who is responsible for leading meetings and representing the subcommittee to the TSC.

4.6.1.3    Subcommittee  Subcommittee Chair / Co-Chair Elections

The Chair or Co-Chair will be elected by members of the subcommittee as of the date the nomination process starts for the election.

4.6.1.4    Subcommittee 4   Subcommittee Voter Eligibility

All members of the subcommittee are eligible to vote.

4.6.1.5    Subcommittee  Subcommittee Election Confirmation

The elected Chair (and/or Co-Chair) is submitted to the TSC for confirmation. The TSC decides to accept the outcome or requests a new voting.

...

Subcommittees operate on a rough consensus basis.  If the subcommittee is unable to reach consensus on what advice to offer, the subcommittee Chair shall raise the issue with the TSC, where a formal vote can be taken, or advise the project that the subcommittee cannot reach consensus. 

4.6.3   TSC subcommittee lifecycle

...

4.6.3.1     Creation 1   Creation of a TSC subcommittee

The TSC decides the creation of a subcommittee in accordance with TSC decision procedure.

...

Members of the sub-committee who want to run for Chair for the subcommittee self nominate

4.6.3.2     Update 2   Update of a TSC subcommittee

The TSC can modify a TSC subcommittee via a TSC decision.  To request such a modification, a request is made to the Akraino-TSC email list.

4.6.3.3     Conclusion 3   Conclusion of a TSC subcommittee

The TSC decides the termination of the TSC subcommittee in accordance with the TSC decision procedure.  The submission of a request to terminate the TSC subcommittee should cover:

• TSC subcommittee name
• TSC subcommittee deliveries: <description of what has been achieved>
• Motivation for termination of TSC subcommittee: <Reason for requesting the termination of the subcommittee>

4.6.4   Subcommittee 4   Subcommittee vs. coordinator

As a guideline, a subcommittee is most appropriate when the task to be addressed involves a relatively stable group of people with a high level of intersection of common involvement.  A coordinator is more appropriate when there is a more dynamic group of people and issues may change frequently. A coordinator is also more appropriate for smaller efforts or topics requiring infrequent meetings.

...