Project Stages Mapping: Criteria and Data
Stage 1: At Large Projects (formerly 'Sandbox')
Criteria | Data |
---|---|
2 TAC Sponsors, if identified (Sponsors help mentor projects) - See full definition on Project Stages: Definitions and Expectations | |
A presentation at an upcoming meeting of the TAC, in accordance with the project proposal requirements | |
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. | |
Upon acceptance, At Large projects must list their status prominently on website/readme |
Stage 2: Growth Stage (formerly 'Incubating')
Criteria | Data |
---|---|
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. | |
Document that it is being used in POCs. | |
Demonstrate a substantial ongoing flow of commits and merged contributions. | |
Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan. | |
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). | |
Since these metrics can vary significantly depending on the type, scope and size of a project, the TAC has final judgement over the level of activity that is adequate to meet these criteria. |
Stage 3: Impact Stage (formerly 'Top-Level')
Criteria | Data |
---|---|
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. | |
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). | |
Other metrics as defined by the applying Project during the application process in cooperation with the TAC. |
Stage 4: Emeritus Stage
Criteria | Data |
---|---|
Projects may be granted Emeritus status via a 2/3 vote from the TAC, majority vote of the Governing Board and with approval from project ownership. In cases where there is a lack of project ownership, only a 2/3 vote from the TAC is required. |