...
- Early-stage projects that the LF Energy TAC believes warrant experimentation.
- New projects that are designed to extend one or more TAC projects with functionality or interoperability libraries.
- Independent projects that fit the LF Energy mission/vision and provide the potential for a novel approach to existing functional areas (or are an attempt to meet an unfulfilled need).
- Projects commissioned or sanctioned by the LF Energy, including initial code for LF Energy Working Group collaborations, and "experimental" projects.
- Any project that realistically intends to join LF Energy Incubation in the future and wishes to lay the foundations for that.
...
- Have an open and documented technical governance, including:
- A LICENSE file in every code repository, with the license chosen an OSI-approved license.
- A README file welcoming new community members to the project and explaining why the project is useful and how to get started.
- A CONTRIBUTING file explaining to other developers and your community of users how to contribute to the project. The file should explain what types of contributions are needed and how the process works.
- A CODEOWNERS or COMMITTERS file to define individuals or teams that are responsible for code in a repository; document current project owners and current and emeritus committers.
- A CODE_OF_CONDUCT file that sets the ground rules for participants’ behavior associated and helps to facilitate a friendly, welcoming environment. By default projects should leverage the Linux Foundation Code of Conduct unless an alternate Code of Conduct is approved prior.
- A RELEASE file that provides documentation on the release methodology, cadence, criteria, etc.
- A GOVERNANCE file that documents the project’s technical governance.
- A SUPPORT file to let users and developers know about ways to get help with your project.
- Complete and approve the Technical Charter and agree to transfer any relevant trademarks to The Linux Foundation or its affiliate, LF Projects, LLC, and to assist in filing for any relevant unregistered ones.
- Have achieved and maintained a Core Infrastructure Initiative an OpenSSF Best Practices Badge at the ‘Passing’ ‘Passing' level.
- Have had a successful license scan with any critical issues remedied.
- Have a defined project mission and scope
- An overview of the project’s architecture and features defined.
- A project roadmap defined, which should address the following questions.
- What use cases are possible now?
- What does the next year look like in terms of additional features and use cases covered?
- Community and contributor growth assessment
- The current number of contributors and committers, and the number of different organizations contributing to the project.
- Demonstrate a sustained flow of commits / merged contributions
- A credible plan for developing a thriving user community, in particular expanding the number of committers and contributors?
- Outline of the plan for the project to complete the requirements for Adopted Stage
- Receive the affirmative majority vote of the TAC.
...
- Demonstrate growth in the project’s community, including
- Growth in the number of commits to the project, number of project committers, and organizational diversity of contributions and committers.
- Production or planned production use of the project by at least two independent end users which, in the TAC’s judgment, are of adequate quality and scope.
- Technical Governance of the project is operational, as measured by:
- A Technical Steering Committee with at least 5 members and a chairperson elected by the members, holding regular open meetings.
- Achievement of the Core Infrastructure Initiative’s OpenSSF Best Practice badge at the ‘Silver’ 'Silver' Level
- Development of a growth plan, to be done in conjunction with their project mentor(s) at the TAC. This plan should address the following points:
- Since these metrics can vary significantly depending on the type, scope, and size of a project, the TAC has final judgment over the level of activity that is adequate to meet these criteria.
- Release plans for the next 18 months.
- Target end-users.
- Identification of any regulatory or standards body requirements for deployment, and plans for implementation.
- Plans for growth of project contributors and committers to support the growth plan. Since these metrics can vary significantly depending on the type, scope, and size of a project, the TAC has final judgment over the level of activity that is adequate to meet these criteria
- .
- Identification of any infrastructure resources needed to fulfill the growth plan.
- Presentation to the TAC of the project’s growth, technical governance, and growth plan.
- Receive the affirmative majority vote of the TAC and Governing Board
...
- 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 fulfilled or are on track to complete the growth plan defined in the Early Adoption stage proposal.
- Have a healthy number of contributions or committers from at least three organizations, with any single organization not composing more than 50% of the contributions or committers. Committers must be identified within the project in a COMMITTERS file.
- Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website).
- Achievement of the Core Infrastructure Initiative the OpenSSF Best Practices badge at the 'Gold' level.
- Present to the TAC and the Governing Board on the fulfillment of these requirements.
- Receive a ⅔ majority vote from the TAC and a majority vote of the Governing Board to move to the Graduated stage. Projects can move directly from Incubation to Graduated status if they can demonstrate sufficient maturity and have met all requirements.
...