...
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 more than 600 committs, by more than 60 contributors over more than 30 repositories. For the latest status/indications on the respective categorie(s), please use the LFX Insights Analytics tool: 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. For the latest status/indications on the respective categories, please use the LFX Insights Analytics tool: 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 The previously reported undertakings for high-level co-operation between some of the Akraino Blueprints as e.g. ELIOT and EdgeX Foundry remains. There are also several cases for The above also applies for the interaction/use of LF Edge EVE and Fledge (e.g. Akraino Blueprint IoT Camera maintenance Blueprint). The initiated by the Akraino API TSC Sub-committee is currently workingon work on assessing the room for potential co-operation among Akraino Blueprint Blueprints and Development Projects remains and it is also set as part of the InterAkraino inter-operability Strategy for one of the Akraino Goals for 2021Goals for 2022. Nevertheless, it is important to also explicitly state, that the Business Objectives and prioroties are set by (and within the Companies that had submitted and drive the Blueprints and respectively allocate their internal resources and set the related Budget for those resources to participate). |
Stage 2 Projects, please skip to Additional Information Requested from All Projects
...
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 (with few new members elected in 2021), 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 |
...