2 TAC Sponsors, if identified (Sponsors help mentor projects) - See full definition on Project Stages: Definitions and Expectations

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.

• The Akraino project has an "upstream first" policy. All Akraino Blueprints and Feature projects that contribute to upstream projects must complete the Upstream Dependency Matrix. The tables should be completed at project induction time (for new projects) and refreshed at release time (for existing projects). As of R4, in order to build a stable release (a release is a release which Downstream and Community can rebuild after a certain long period of time), Upstream will need to specify upstream repositories completely and with corresponding version/branch information. Also Upstream Sub-committee recommends to use tag instead of branch if possible.The list of each Blueprint Upstream Dependendency Matrix and Upstream Project information can be viewed at: https://wiki.akraino.org/display/AK/Upstream+Dependency+Matrix+and+Upstream+Project+Information?src=contextnavpagetreemode

Upon acceptance, At Large projects must list their status prominently on website/readme

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.

Within Akraino, there is currently

• 18 Blueprint (Integration) Projects (https://wiki.akraino.org/display/AK/Approved+blueprints?src=contextnavpagetreemode
• 4 Blueprint proposals (https://wiki.akraino.org/display/AK/Blueprint+Proposals?src=contextnavpagetreemode
• 10 Feature (aka Development) Projects

Document that it is being used in POCs.

Each Blueprint (Integration) project is required to submit the followng set of  Documents:

1. Architecure description, 2. API description, 3. Test description, 4. Installation Guide, 5. Test description. The deployment status of the Blueprint, being PoC, Demo or Commercial is presented/indicated in the Blueprint Architecture document.

Demonstrate a substantial ongoing flow of commits and merged contributions.

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.

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

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.

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.

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.

Demonstrate evidence of interoperability, compatibility or extension to other LF Edge Projects. Examples may include demonstrating modularity (ability to swap in components between projects).

Adopt the Foundation 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.

Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website).