Introduction

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 Mission of Akraino

...

 

The Akraino Edge Stack Technical mission to focus on following areas

1.                                1.            Create end to end configuration for a particular Edge Use case which is complete, tested and production deployable meeting the use case characteristics {Integration Projects - Blueprints}.
   Production deployable means the blueprint has passed unit and integration testing and meets the blueprint’s use case characteristics.
2.                                2.            Develop projects to support such end to end configuration. Leverage upstream community work as much as possible to avoid duplication.  {Feature Projects}
3.                                3.            Work with broader edge communities to standardize edge apis {Upstream Open Source Community Coordination - For example, Socialization, so community tools and Blueprints can interoperate. This work can be a combination of an upstream collaboration and development within the Akraino community [i.e. a feature project]}
4.                                4.            Encourage Vendors and other communities to validate Edge applications and Virtual Network Functions on top of Akraino blueprints {Validation Project - ensures the working of a Blueprint}

In order to have focused work in support of initial releases, the Akraino community preference is to support Edge Blueprints related to enterprise and industrial IoT, and carrier edge network use cases. Board has the authority to define, modify, prioritize any additional industry sectors that need to be supported by the Akraino Edge Stack releases.

The Edge cloud stack placement could vary between Telco Offices to Customer premise and anything in between. Akraino Edge Stack community blueprints should be capable to deploy and address different edge cloud placement options. 

As an example, the picture below illustrates the enterprise edge and carrier edge network Edge use cases and possible edge placement.

 Image Added                      

Figure 1 - Sector 1: Carrier edge network edge use case and edge placement

Image Added

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

...

This document covers the Akraino project lifecycle. The Release Lifecycle will be documented in the  wiki.

3.3.2   Akraino

...

Project Types

Akraino will support three categories  of projects and upstream coordination activities related to the projects as shown in Figure 3 and further illustration are available under the section 3.3.2.1, 3.3.2.2 and 3.3.2.3 of this document.

The Akraino Edge Stack Community goal is to deliver fully integrated and production deployable solution for the users.  The combination of Feature projects (developing missing edge functionalities on non-upstream open source components), Integration projects (integrated end to end stack) and End To End (ETE) validation projects of the blueprints along with edge applications running on top of it, delivers the production deployable solution needed by the industry.

Akraino community uses upstream-first principle to avoid technical debt on the upstream open source components: Akraino projects should not carry patches against upstream projects, but collaborate with and contribute designs and patches to the respective upstream projects to address gaps. Exceptions must be approved by the TSC.

 Image Added

Figure 3 – Akraino Edge Stack Project Types & Scope

3.3.2.

...

1   Akraino Feature Projects  (a.k.a Development Project)

The Akraino Edge Stack Feature projects develop edge features, functionalities, interfaces and modules required by an Akraino blueprint or multiple Akraino blueprints to satisfy the Edge use cases and requirements. Feature projects focus on the development work required by Akraino community instead of upstream open source components.

...

The feature project should address the functionality needed by Akraino specified use cases. During the feature project creation the scope should define whether it will support a single or multiple blueprints. Illustration is shown on Figure 4.

Image Added

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

...

3.3.2.

...

2   Akraino Integration Projects (Blueprints)

Akraino Integration Projects create or modify Akraino Blueprints to support specific edge use cases. 

...

Community members will use a template for use case characteristics, blueprint family and blueprint approved by the TSC to describe the hardware, software, deployment configurations, workload characteristics when requesting the creation or modification of an Akraino Blueprint. The requestor should demonstrate the following aspects to the TSC:

1. Each initial blueprint is      encouraged is encouraged to take on at least two Committers from different companies
2. Complete all templates      outlined in this document
3. A lab with exact      configuration required by the blueprint to connect with Akraino CI and      demonstrate CD. User should demonstrate either an existing lab or the      funding and commitment to build the needed configuration.
4. Blueprint is aligned with      the Akriano with the Akraino Edge Stack Charter
5. Blueprint code that will      be will be developed and used with Akraino repository should use only Open Source      software components either from upstream or Akriano Akraino projects.
6. For new blueprints      submission, the submitter should review existing blueprints and ensure it      is it is not a duplicate blueprint and explain how the submission differs . The      functional fit of an existing blueprint for a use case does not prevent an      additional blueprint being submitted.

...

The below diagram (Figure 5) illustrates the process.

 Image Added

Figure 5 – Akraino Blueprint Creation Process

3.3.2.2.1 Akraino 1   Akraino Blueprint Family and Life Cycle of Blueprints

At the Family level, blueprints are differentiated by high level technical attributes which are immutable. Removing or inserting one of these attributes would change any pod delivered by the blueprint to such an extent that it could not reasonably be considered part of the same blueprint family.

...

Below picture illustrates the Network Cloud blueprint family and POD level specification which allows possibility of different component level.

Image Added

Figure 6 - Illustration of blueprint family and its blueprints

3.3.2.2.2 Akraino 2   Akraino Use Cases, blueprint families and blueprints

Akraino use cases are business driven and must include a clear description of business requirements, operational considerations (cost, user interface, scale, power restrictions, etc…) , and applications expected to operate on the Blueprint. Any community member can submit a use case for review by TSC for further development.

...

Blueprint templates are required to create or modify blueprints within a blueprint family.  In some cases, new or modification to a blueprint may require updates to existing use case templates and/or blueprint family templates and the submitter should make changes to all 3 templates as required.

Image Added

Figure 7 - Templates needed for blueprint family and blueprint creation and modification

When one or more fully defined blueprint addresses the same use case common test cases should be adopted where possible.

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.3.2.2.2.2   Template 2 Template 2 - Blueprint family template

Below is a sample Blueprint family template. The full template will be maintained on the Akraino Wiki.

3 3.3.2.2.2.3   Template 3 Template 3 - Blueprint species template

Below is a sample Blueprint template defining an Akriano Akraino species. The full template will be maintained on the Akraino Wiki.

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 Validation labs are owned by an Akraino community company, organization or participant.

Comprehensive validation of the blueprint within the community will include testing of the OS layer, the undercloud layer, the upper cloud layer, VNF layer and the application layer. Test results should be available to the Akraino Edge Stack community for review via automated push to the wiki.  Any defects identified should be logged in JIRA and assigned to the responsible party.  When defects are identified in upstream components, Akraino coordinators should be assigned defect ownership.  Akraino coordinators will work with upstream communities to resolve defects. For defects that do not involve upstream communities, impacted Protect Technical Leaders should be assigned defect ownership.

...

An automation framework should be used for test procedures and leverage existing test automation suites for upstream projects as required.  It is the responsibility of the blueprint submitter to ensure that the Edge Flock Validation and Community CI labs can support comprehensive validation of the blueprint and cover all use case characteristics.  

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

The Akraino Community CI labs are owned by the Akraino community and LF. Access is controlled by LF best practices.

...

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

3.2.2.3.2 

...

 Blueprint and application testing in Akraino Edge

...

Validation lab

Akraino Edge flock Validation labs are owned by an Akraino community company, organization or participant.

The Flock Validation labs can be owned and operated by the supplier of the lab with limited access or no access to the hardware but results of the validation testing need to be shared to the community.

TSC will propose a subcommittee to maintain and coordinate the Flock Validation labs.

Blueprint, application and VNF testing may be performed over a number of Flocks Validations labs concurrently in a coordinated manner as required.

• The Flock Validation labs should be able to connect to Akriano Akraino Edge Stack CI hosted by LF to pull in Akraino blueprints for the validation. Necessary Firewalls can be opened by the Akriano Akraino Community on request.
• All Flock Validation labs should be available most of the year for the community use and if the lab is not used for validation more than 3 consecutive months then it will be removed from the community list.
• Hardware and Network configuration used within the Flock Validation labs should be declared and information should be documented in the wiki
• All the Flock Validation labs addition, modifications or removable need to be approved by TSC
• All historic results (minimum of 1 year) of blueprint validation, Applications and VNF testing should be maintained in the wiki.

3.2.2.3.2.1 Blueprint 1   Blueprint testing

The test plan and associated test cases to validate the blueprint will be published on the Akraino wiki and reviewed by blueprint stakeholders.  

• The lab configuration should support functional, performance, security, and other test cases for the blueprint and cover the full stack for the blueprint. 
• Any license or support beyond the Community supplied software should be funded, owned and operated by the flock Validation supplier

Open source test tools and vendor tools with appropriate configurations should drive test traffic profiles that mimic in-scope use cases.  Akraino coordinators will engage upstream open source communities to get access to upstream community labs for the Akraino blueprint test team.  The submitter is responsible to establish access to necessary vendor labs.

3.2.2.3.2.2 Application 2   Application and VNF testing

Akraino blueprint releases ensure that applications and virtual network functions (VNFs) can on-board and operate effectively on the Akraino solution. Flock Validation labs can be further used for the validation of Edge applications and VNFs.

...

Submission of results to the Akriano Akraino community is optional in case of commercially sensitive applications.

...

Individual blueprint within a blueprint family shall not be tied to the overall Akraino release schedule (e.g. 6 months). An Akraino release can be composed of 1 to N fully verified blueprints or individual feature projects. As such the number of blueprints and contributing projects within a given Akraino release may vary overtime. Figure 8 show this with two blueprint families, Network Cloud and the imaginary Canis Edge and a number of individual blueprint species within each family.

Image Added

Figure 8 - Project and AKraino Akraino release lifecycles

Each project shall provide an expected release plan document published with the blueprint on the wiki.  From the project schedules an overall Akraino release schedule shall be maintained and published.

...

The life cycle of a project is depicted in the following diagram:

...

Image Added

Figure 9 – Akraino Project States

To move from one state to the next state, the Project Team has to formulate a Kick-Off release review to the TSC, by specifying its goal to move up the Project Lifecycle ladder.

Note 1: Project proposals are posted in the “Proposed Projects” section of the Akraino wiki.  Approved projects are posted to the “Approved Projects” section of the Akraino wiki.

...

A project’s release cycle may be tailored by allowing some exceptions to the normal release process. Tailoring may be initiated in two ways:

1. By the TSC voting      membersvoting members: TSC voting members reserves the right to allow changes to the      process in order to meet criteria that were initially unknown.
2. By Project Team Lead: Any      project team lead can email TSC voting members to request tailoring the      process the process for a particular release. The key point in tailoring is to      anticipate as much as possible, to justify the request, and document the      request in the wiki.

Tailoring practices will be documented as we progress through our releases. The TSC should respond to requests in a timely manner.

...

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 at least two 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 CI/CD Sub-Committee, TSC and presented to broader Akraino community
• Project Contributors have provided a validation lab with exact configuration required by the project to connect with Akraino CI and demonstrate CD. The environment should be reviewed and endorsed by the Architecture CI/CD Sub-Committee.
• Project is active and contributes to Akraino: The project demonstrates a stable or increasing demonstrates increasing number of commits and/or number of contributions across recent releases. Contributions are commits which got merged to a repository of an Akraino commits that have been to an Akraino repository project or a related upstream project. Commits Commit examples 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 at least two independent end users ( typically, service providers ).who have publicly documented their support on the Akraino wiki and within the accompanying project documentation.

3.3.7.3   Core 3.3.7.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 Review

3.4  Amendments to the Technical Community Document

2   Release Review

• 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.4   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 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.

...

The TSC functional roles of chair and co-chair will be held by TSC members.

Image Added

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.

...

A coordinator can act as the ambassador to external upstream communities in communicating the requirements need to be addressed in the upstream community on behalf of Akriano Akraino Feature or Blueprint project. TSC can appoint either Akriano Akraino level or project level coordinators to facilitate upstream coordination work. Coordinators can act as a technical liaison only and cannot represent strategy aspects of the Akriano Akraino which will be handled by TSC.

...

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

...

Coordination Area Termination.

A coordination area can be terminated by sending an email to the TSC via the Akraino-TSC email list.  The email shall have the following.

...

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 4.4.3.2.1 section (TSC approved 9/5/19) 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.

There are no limits to the number of terms an individual can serve.

...

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.

The CIVS election wil rank all standing candidates from 1 to N.

Only one (1) person from any company, or a group of related companies can be elected as a TSC member at any given time. (TSC approved 9/5/19)

If any organization entered more than the permitted limit of electable candidates all excess candidates shall be removed from If any organization entered more than the permitted limit of electable candidates all excess candidates shall be removed from the results from the least ranked upwards until the organization  limit is reached.

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, no longer able to perform the TSC duties, moved to a different company (TSC approved 9/5/19), 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 . (TSC approved 9/5/19)

In all above cases, the TSC member may inform via an email to the TSC email list, an interim election may be called by the TSC for that single position within 60 days of the notification from the leaving TSC member. Interim election can be used to reelect the open TSC position. The period of the TSC member elected using the interim election can be up to next full election. (TSC approved 9/5/19)

In an interim election, any organization eligible contributors (TSC approved 9/5/19) may only enter candidates if their current representation on the TSC is an organization may only enter candidates if their current representation on the TSC is below their organization’s TSC Member limit.

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

...

3.4 TSC Member Contributions (TSC approved 9/5/19)

Contributions to the Akraino Community may be counted as either ‘individual’ or “individual contribution on behalf of a company”. A ‘individual’ contribution is made by a named individual. An “Individual contribution on behalf of a company” are governed by the policy of an individual’s Organization to whom they were affiliated at the time of the contribution. Individual contributions cannot be transferred to other individual. 

For the TSC election purpose, the Organization can request the TSC to count an “individual contribution on behalf of a company” to another named individual of their Organization at any time regardless of whether the original Contributor remains in or has left the Organization. If an individual Contribution leaves an Organization that Organization may at their sole discretion decide to: retain all their Contributions and reallocate them to another named individual within their Organization (for the TSC election purpose). Organization should inform TSC of such details of contributions and reallocation in writing.

OR

agree to transfer all their Contributions to the individual’s new Organization thereby releasing all interest in the previous Contributions to the Individual’s new Organization. Organization should inform TSC of such details of contributions and releasing in writing.

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

• Identifying and Recruiting Akraino Localized Organizations

4.5.1 Identifying and Recruiting Akraino Localized Organizations

The TSC shall be responsible for identifying and recruiting suitable organizations amenable to cooperation in establishing centers providing technical and marketing resources in geographically distinct areas to support Akraino blueprint teams and groups based in those areas. Such "localized" areas are typically characterized by language, time-zone, and international differences, for example the TSC might seek to establish a South America center, an Africa center, a Shenzhen center, etc.

When an organization has been identified, TSC members shall meet to discuss and evaluate the organization to determine its suitability, based on the following technical, marketing, and operational criteria:

• The organization must present a public website with goals and mission statement indicating a non-profit, open, collaborative nature, preferably with .org domain suffix. Examples include foundations, consortiums, development communities, user communities, etc.
• The organization must be a technical organization, with emphasis on open source software and hardware
• The organization must be engaged in sufficient marketing and promotional efforts, including online and social media. The organization must be able to incorporate Akraino web links, material, and blueprint documentation in substantial, appropriate, and prominent manner
• The organization may be associated with academic institutions
• The organization may have sponsor companies
• The organization must demonstrate support, or an acceptable plan of support, for a range of CPU types, including but not limited to x86, Arm, RISC, SoC (e.g. FPGA with CPU cores)
• The organization may provide working area(s), including WiFi or other Internet capable of online video/audio collaboration. Server and other development hardware resources are preferred but not required
• The organization must agree to comply with Policy and Operational Procedures as listed on the Akraino Regional Communities page

During the discussion and evaluation phase, the TSC may at its option nominate and vote to approve an Akraino representative to act as "point person" to work with the candidate organization's senior / authorized management to resolve concerns, negotiate objectives and requirements, gather facts and data, and otherwise act on behalf of the TSC. The point person may be a TSC member, subcommittee chair or co-chair, or other. The point person may recruit others to help with the effort. As one example, the TSC might designate the "Outreach Subcommitee" chair as the point person, who then might recruit helpers from other subcommittees or blueprint projects.

After the discussion and evaluation phase, including updates from the point person if one has been designated, the TSC shall vote to decide whether to formally engage with the candidate organization. Should the vote succeed, the TSC shall present the candidate organization, along with its evaluation results, to Akraino's parent Linux Foundation management for further, formal action.

4.6   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 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 From time to time, (a) the TSC may amend or introduce alternative approaches to convene and run subcommittees and (b) decide to disband subcommittees that are no longer active or that no longer have any active members.

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.  

4.6.1.2   Subcommittee Chair / Vice Chair

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 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.3.1   Subcommittee Interim Elections

In case a subcommittee Chair or Co-Chair steps down or isno longer able to perform subcommittee duties (for example, moved to the TSC.

4.6.1.3    Subcommittee Chair / Co-Chair Elections

The a different company, no longer active in Akraino, etc), an interim election may be called by the TSC. The term of the subcommittee Chair or Co-Chair will be elected by members of the subcommittee as of the date the nomination process starts for the electionelected as a result of the interim election can be up to the next full election.

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

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. 

Glossary

...