Completed by: Ike Alisson
Submitted to TAC Mail List: -
Presented on TAC Weekly Call: 2022/02/XX
Below is a self-assessment submitted by TSC Chair/Maintainers of the Project. Comments/questions/feedback is welcome either a) in the Comments at the bottom of the page or b) during the TAC call when information is presented
Stage 1: At Large Projects
Stage 2 and Stage 3 Projects also requested to complete this section, as PLD acceptance criteria requires meeting current as well as prior stage requirements
Stage 1 Criteria (from the PLD) | Meets / Needs Improvement / Missing / Not Applicable | Supporting Data (if needed, include links to specific examples) |
|---|---|---|
2 TAC Sponsors, if identified (Sponsors help mentor projects) - See full definition on Project Stages: Definitions and Expectations | Meets | XXXX @Tina Tsou |
The typical IP Policy for Projects under the LF Edge Foundation is Apache 2.0 for Code Contributions, Developer Certificate of Origin (DCO) for new inbound contributions, and Creative Commons Attribution 4.0 International License for Documentation. Projects under outside licenses may still submit for consideration, subject to review/approval of the TAC and Board. | Meets |
|
Upon acceptance, At Large projects must list their status prominently on website/readme | Meets | https://www.lfedge.org/projects/akraino/ |
Stage 1 Projects, please skip to Additional Information Requested from All Projects
Stage 2: Growth Stage
Stage 3 Projects also requested to complete this section
Stage 2 Criteria (from the PLD) | Meets / Needs Improvement / Missing / Not Applicable | Supporting Data (if needed, include links to specific examples) |
|---|---|---|
Development of a growth plan (to include both roadmap of projected feature sets as well as overall community growth/project maturity), to be done in conjunction with their project mentor(s) at the TAC. | Meets | Within Akraino, there is currently
|
Document that it is being used in POCs. | Meets | Each Blueprint (Integration) project is required to submit the followng set of Documents:
|
Demonstrate a substantial ongoing flow of commits and merged contributions. | Meets | There had been 623 committs, by 62 contributors over 36 repositories. https://lfanalytics.io/projects/lfedge%2Fedgex-foundry/dashboard |
Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan. | Meets | There have been more than 17.00K builds. https://insights.lfx.linuxfoundation.org/projects/lfedge%2Fakraino-edge-stack/dashboard |
Demonstrate evidence of, or a plan for, interoperability, compatibility or extension to other LF Edge Projects. Examples may include demonstrating modularity (ability to swap in components between projects). | Meets | There are undertakings for high-level co-operation between Akraino ELIOT and EdgeX Foundry. There are also several cases for interaction/use of LF Edge EVE and Fledge (e.g. Akraino Blueprint IoT Camera maintenance Blueprint). Akraino API TSC Sub-committee is currently workingon assessing the room for potential co-operation among Akraino Blueprint and Development Projects as part of the Inter-operability Strategy for one of the Akraino Goals for 2021. |
Stage 2 Projects, please skip to Additional Information Requested from All Projects
Stage 3: Impact Stage
Criteria | Meets / Needs Improvement / Missing / Not Applicable | Supporting Data (if needed, include links to specific examples) |
|---|---|---|
Have a defined governing body of at least 5 or more members (owners and core maintainers), of which no more than 1/3 is affiliated with the same employer. In the case there are 5 governing members, 2 may be from the same employer. | Meets | The Akraino Project Community Guiding Principle is to operate transparently, openly, collaboratively, and ethically. All (Akraino) Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders. The structure of the Akraino Technical Community consists of multiple projects and a Technical Steering Committee (TSC), with 20 members, that spans across all projects and with representatives from variety of CSPs (Communication Service Providers) Companies. For detailed information on the Akraino TSC Members and the companies they represent, you may look at the: https://wiki.akraino.org/pages/viewpage.action?pageId=4456453 |
Have a documented and publicly accessible description of the project's governance, decision-making, and release processes. | Meets | Akraino Community GovernanceThe Akraino Community functions as an Open Source Project, with a set of rules and leaders elected and approved from within the participants of the project. The following serve as the official sources for Akraino Governance.
Akraino Project Lifecycle States and ReviewsAkraino projects’ life cycles defines five (5) states that projects goes through. A project lifecycle may extend across multiple projects and Akraino releases. The procedure of moving from one state to the next one is independent from the Akraino Release lifecycle and the pace depends on each individual project. In order to effectively review Project progress, four (4) Reviews are built-in to the project life cycle, namely, Proposal, Incubation, Mature, Core (Archived Project state can be assigned for multiple reasons. Either project has successfully been completed and its artifacts provide business values, or project has been cancelled for unforeseen reasons (no value anymore, technical, etc.). Project in any state can be Archived through a Termination Review.
https://wiki.akraino.org/display/AK/Community+Governance Akraino Technical Community DocumentFor detailed and/or additional insight information on the Akraino Technical Community Document description, you may look at: https://wiki.akraino.org/display/AK/Akraino+Technical+Community+Document |
Have a healthy number of committers from at least two organizations. A committer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project. | Meets |
|
Demonstrate evidence of interoperability, compatibility or extension to other LF Edge Projects. Examples may include demonstrating modularity (ability to swap in components between projects). | Meets | There are initiatives for co-operation with LF Edge EVE (as an Operating System) and LF Edge Fledge (as a Platform) Projects by Akraino ELIOT as well as EdgeX Foundry Project. The initiated inter-operabiity is at an initial stage and coming Release alignment planing is on-going. |
Adopt the Foundation Code of Conduct. | Meets | https://lfprojects.org/policies/code-of-conduct/ |
Explicitly define a project governance and committer process. This is preferably laid out in a GOVERNANCE.md file and references a CONTRIBUTING.md and OWNERS.md file showing the current and emeritus committers. | Meets | The information input on Akraino Poject Governance provided previously above. 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.Committer Lifecycle. 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. In the event that a project has no active committers (e.g., due to resignations, etc.), the TSC may appoint an interim Committer from a project’s active Contributors. This term shall last until the next release date, after which time the Committer must stand for election from amongst other Committers on the project to maintain his or her status. In this special case, approval requires a majority of committers who respond within two weeks. If no one responds by the deadline, then the committer status is approved. This provision allows a project to continue development following an unexpected change in personnel. 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. |
Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website). | Meets |
Additional Information Requested from All Projects
Additional Information Requested from All Projects | Supporting Data (if needed, include links to specific examples) |
|---|---|
Intention for the upcoming year (Remain at current stage OR advance towards the next Stage) | Advance for R4 with a preliminary infographic for New/Additional Rel. 4 Akraino Blueprints/Integration Projects:
|
Include a link to your project’s CommunityBridge Insights page. We will be looking for signs of consistent or increasing contribution activity. Please feel free to add commentary to add color to the numbers and graphs we will see on Insights. | https://insights.lfx.linuxfoundation.org/projects/lfedge%2Fakraino-edge-stack/dashboard |
How many maintainers do you have, and which organizations are they from? (Feel free to link to an existing MAINTAINERS file if appropriate.) | Maintainers are at Akraino Blueprint and Development project level and therein varies accordingly. |
| What do you know about adoption, and how has this changed since your last review / since you joined the current Stage? If you can list companies that are end users of your project, please do so. (Feel free to link to an existing ADOPTERS file if appropriate.) | This again varies among Akraino Blueprints and Development projects. |
| How has the project performed against its goals since the last review? (We won't penalize you if your goals changed for good reasons.) | The targets in terms of Blueprints evolvement/maturity via the above inidcated 4 (four phases) and adding new Blueprints/Development projects had been in line with the set for 2020 targets. |
| What are the current goals of the project? For example, are you working on major new features? Or are you concentrating on adoption or documentation? | The focus is on the coming Akraino R4 as wellas as outlining the type and use of APIs by all the Akraino Blueprints and Development Projects in order to outline a potential plan and scope for possible inter-operability among the Akraino Blueprints/Development Projects. |
| How can LF Edge help you achieve your upcoming goals? | LF Edge can provide an insight on synergy between existing Architectures e.g. 3GPP 5G SBA, ETSI MEC, TM Forum ODA LF ONAP and identify a Common Architecture Framework that all LF Edge Projects can follow and through compliance to that Common Architecture Framework achieve and inter-operatibility and scalability among the LF Edge Projects. |
| Do you think that your project meets the criteria for the next Stage? | Yes. Akraino Project is ready for Rel. 4. |
| Please summarize Outreach Activities in which the Project has participated in (e.g. Participation in conferences, seminars, speaking engagements, meetups, etc.) | F2F Akraino TSC meeting in March 2020 and virtual F2F TSC Conference in September 2020 as well as participation at various Conferences as ONES and Edge Computing World and varios guest speakers from various Companies and SDOs as ETSI MEC, ETSI NFV, Verizon, Google, HPE, Telefonica. |
| Are you leveraging the Technical Project Getting Started Checklist? If yes, please provide link (if publicly available). | Akraino benefits from the following Getting started Project description.
https://wiki.akraino.org/display/~TapioTallgren/Getting+started+with+Akraino 2. Getting started with Akraino Project: Process, Project Review, recommend and Documentation Process, Project review and recommend sub-committee: Finalize request Templates for Blueprint and feature project, document to allow developers to get started. Develop and evolve the process by which blueprint and feature project proposals are reviewed, and ultimately approved with recommendation required documentation.Template 1 - Use case template, Template 2 - Blueprint family template, Template 3 - Blueprint species template |
