References:
Draft Incubation Review Slides - Use this link to view and comment. If you need Editor permissions contact LJ Illuzzi
Project States
Project State | State Summary |
|---|---|
| Candidate | Projects looking to integrate with the LFN umbrella of projects may be inducted at any lifecycle state, provided it meets The Linux Foundation's proven best practices for success. |
| Sandbox | The Sandbox stage is designed to provide a lightweight entry process for new projects that align with the LFN mission and meet the It is ideal for early-stage projects that require time to explore their community, governance, and technical roadmap. Project proposals should meet the |
| Incubation | The project meets all the conditions for the Sandbox stage, and in addition: The Incubation stage is for projects that have demonstrated progress toward open source best practices, including contributor diversity and open governance, and have a documented release process. Projects in this stage should be actively working on integration with other LFN projects, participating in cross-LFN initiatives, and/or contributing to extending or strengthening the LFN scope. |
Graduated | The project meets all the conditions for the Incubation stage, and in addition: The Graduated TAC Project stage is for projects that have met the demonstrated project diversity, adherence to open source best practices, active participation in LFN, and have a documented release process and a history of following it. Projects in this stage have a voting representative on the TAC. |
| Archived | A project can be Archived if it has received no significant commits within the previous 12 months or if the Project's TSC requests archiving. An Archival Review will be initiated to determine if the project meets the criteria for archiving. |
Process
Incubation Review
Similar to the LFN Entry Review, proposals for projects moving to the Incubation state will be reviewed by the TAC and the Board. TAC Incubation Reviews should happen periodically, with the goal of ensuring that the project remains healthy. The reviews will be based on the content available from LFX tools to minimize the burden on the project's community.
Criteria for Incubation Review
Mandatory criteria for successful completion of the Incubation review is the documented demonstrable progress since induction toward open source best practices. This would include but is not limited to contributor diversity and open governance, and the release process.
As an additional (non-mandatory) guideline, the project should show demonstrable progress in marketplace adoption. This may be measured by instances of the project in production or the project being embedded in other open source projects.
As part of Incubation Reviews, the TAC should identify how the project fits with other LFN projects, including any overlap or harmonization potential.
Outcome for Incubation Review
As an outcome of the TAC's Incubation Review, the TAC will provide the following feedback to the LFN Governing Board for use as input to the LFN Board's Incubation Review:
- Summary of findings
- Recommendation to accept the project into the Incubation stage or not.
Board Incubation Review
It is up to the Board to define its own criteria and process for the Board's Incubation Review. The TAC strongly recommends the Board make its Incubation Review criteria and process public and accept design input from the public. The reviews will be based on the content available from LFX tools to minimize the burden on the project's community.
Budget Guidance: The TAC recommends to the board that any new Incubation project not erode existing TAC project budgets.
Criteria Guidance:
This table is provided as guidance to a Project seeing induction or promotion to the next tier.
Sandbox | Incubation | Graduated | Comments | |
|---|---|---|---|---|
Code Scanning | An intake scan is conducted to ensure basic security and license compliance. | Scanning is done on an ad-hoc cadence to catch any potential issues early, allowing for timely resolution. | In addition to regular scans, mature tooling and processes are in place to scan all new code submissions, ensuring continuous security and license compliance. | Codeql is used |
| Seed code hand off | A date for seed code handoff is planned and communicated to stakeholders. | Seed code handoff is completed. It's mandatory at this stage to ensure that the project has a solid foundation to build on. | At this stage, the seed code handoff is already completed (mandatory). The project is now focusing on iterating and improving upon this initial codebase. | Complete |
| Coding Standards | Coding standards are loosely defined, allowing for flexibility and creativity in the early stages of the project. | A moderate set of coding standards is enforced to ensure code quality and maintainability without stifling innovation. | Strict coding standards are enforced to ensure high code quality, maintainability, and consistency. Regular code reviews are conducted to ensure these standards are adhered to. | Contained in CONTRIBUTING.md. Pending PR merge |
| Development Governance | Sandbox | Incubation | Graduated | |
Adding/Removing Committers | Mandatory - It's essential at this stage to build a diverse and inclusive team of committers to facilitate the project's progress. | Mandatory - The need for committers may shift as the project grows and evolves, hence it's necessary to have a mechanism for adding/removing them. | Mandatory - As the project matures, maintaining the right set of committers is crucial to ensure high quality and continuous progress. | In place |
| Adding/Removing PTLs (Project Team Leads) | Not required at this early stage, roles might be more informal and fluid. | Mandatory - As the project grows, it's necessary to have designated leaders (PTLs) steering different aspects of the project and a process to add or remove them. | Mandatory - At this mature stage, the mechanism to add/remove PTLs is crucial for maintaining effective leadership and governance. | Defined in Governance under "Project Roles". |
| Sub-Project Lifecycle | Not required at this early stage, the focus is on the core project. | Adding a sub-project - The project may grow and expand into different areas, requiring the addition of sub-projects. | Adding, advancing, and archiving a sub-project - As the project matures, there's a need for mechanisms to add new sub-projects and advance or archive them based on their activity and relevance. | In place |
| Sub-Projects Without a Designated Lead | Allowed - At this stage, sub-projects might not yet be formalized | Not recommended - It's important to have a designated lead for each sub-project to ensure its progress and alignment with overall project goals. | Not allowed - At this mature stage, every sub-project must have a designated lead to ensure effective management and progress. | Defined in Governance under "Project Roles". |
| Dispute Resolution | Not mandatory, but it's beneficial to have some basic dispute resolution mechanism. | Mandatory - As the project and its community grow, it's important to have a defined process for resolving disputes. | Mandatory - With a mature and larger community, a clear dispute resolution process is crucial to ensure a healthy and harmonious community. | Defined in Governance |
| TSC/TOC Governance | Appointments OK - At this early stage, key roles can be appointed to steer the project. | Some Meritocracy - As the project progresses, the governance should start to transition towards a merit-based system, though some roles might still be appointed. | Full Meritocracy - At this mature stage, all governance roles are based on merit. Contributors who have demonstrated their commitment and made significant contributions earn their roles. | Appointment model in place until the project grows |
Documentation | Sandbox | Incubation | Graduated | |
Technical Documentation | Build - Initial creation of technical documentation to guide early adopters and contributors. | Build, deploy - Comprehensive technical documentation is developed and deployed, covering the necessary details of the project's functionality. | Build, deploy, test, debug, upgrade - Extensive documentation is maintained, providing instructions for various tasks, including testing, debugging, and upgrading the project. | Each Release is documented |
Contributor onboarding Documentation | Not required at this early stage. | Simple - A basic set of documentation is made available to guide new contributors. | Detailed - Comprehensive documentation is provided, covering all aspects of contributing to the project, from setting up the development environment to submitting patches. | Add a modified copy of Contributing file to Github/Governance repo. Reference: https://github.com/l3af-project/l3afd/blob/main/docs/CONTRIBUTING.md Pending PR Merge |
| Company Diversity (past 12 months) | variable | variable | Minimum 6 companies required to maintain diverse and balanced representation. | Walmart, some contribution from University of Delhi |
# of Contributors | Few - At this early stage, the focus is on setting up the project and attracting initial contributors. | 10 or more as a target - As the project grows, it attracts more contributors. | More than 2 dozen - As the project matures, the number of contributors increases, reflecting the project's growing community and impact. | 6-8 contributors |
| Release Management | RM consultation with LFN (minimum) - At this stage, the release management process is being set up with guidance from LFN. | Processes established and documented - The release management processes are well-defined and documented, providing clear guidance to the project community. | Processes followed to deliver a release - Mature projects should be following a well-established, documented release process to deliver each release. | In place |
| CI/CD | Manual - At this stage, the project might rely more on manual methods for integration and deployment. | Somewhat Integrated - The project starts to integrate some aspects of CI/CD into their development process. | Mostly Integrated - Most parts of the development process are automated through CI/CD, improving efficiency and reliability. | In place. Using Github |
| Adoption | Not a focus at this stage. | Not a focus at this stage. | At least one end user - For a graduated project, it's expected that it has been adopted by at least one end user. | In production at Walmart (runs Black Friday) |
| Security design principals | Not a focus at this early stage. | OSSF Scorecard has been established and is being tracked as work in progress | OSSF Scorecard is 80% to "Passing" or better - Mature projects are expected to maintain or improve their OSSF Scorecard performance, demonstrating a continuous focus on security. | On track |