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 | |
Adherence to the Foundation IP Policy | |
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. |