Update lifecycle policy document#13
Conversation
| * **Governing Board (GB)**: This board oversees the Foundation. | ||
| * **Technical Advisory Council (TAC)**: The Foundation's TAC includes TSC representatives from all Technical Projects and representatives of the premier members. | ||
| * **Technical Project**: Any project part of the NeoNephos Foundation. | ||
| * **Technical Advisory Council (TAC)**: The Foundation's TAC includes TSC representatives from all Technical Projects and representatives of the Premier Members. | ||
| * **Technical Project**: Any project that is part of the NeoNephos Foundation. | ||
| * **TAC Project**: A Technical Project that has been granted voting privileges within the TAC. | ||
| * **Technical Steering Committee (TSC)**: Each project is managed by a TSC. The project defines how the TSC operates. A TSC appoints a project representative to the TAC who speaks on behalf of the project. |
There was a problem hiding this comment.
I'd rather not have these terms re-defined here; instead it should just point to the Directed Fund Charter or Technical Charter as appropriate
| ## Technical Charter and Intellectual Property (IP) Transfer | ||
|
|
||
| All Technical Projects must have a complete Technical Charter that has been approved by the Linux Foundation Europe. | ||
|
|
||
| Technical Projects must also agree to transfer any relevant trademarks and assets (source code repository, social media accounts, domain names, etc.) to Linux Foundation Europe for the benefit of the NeoNephos Foundation, and to assist in filing for any relevant unregistered ones. | ||
|
|
||
| This is a requirement for all stages of the project lifecycle, including the Sandbox Stage. |
There was a problem hiding this comment.
I'd recommend moving this to the Sandbox Stage requirements.
| * Projects are accepted per the Voting Requirements outlined in each stage. | ||
| * Satisfaction of the requirements of the initial stage of the project. The TAC will determine the appropriate initial stage for the project. The project can apply for a different stage via the review process. | ||
| * Projects must find a TAC Sponsor to champion the project and provide mentorship as needed. | ||
| * Projects must provide a Technical Charter and agree to transfer any relevant trademarks and assets to the NeoNephos Foundation (see above). |
There was a problem hiding this comment.
Replace with the following:
Complete and approve the Technical Charter and agree to transfer any relevant marks, domains, accounts, and other assets to Linux Foundation Europe
| * The TAC may ask for changes to bring the project into better alignment with the NeoNephos Foundation (adding a governance document to a repository or adopting a Code of Conduct, for example). The project will need to make these changes in order to progress further. | ||
| * Projects are accepted per the Voting Requirements outlined in each stage. | ||
| * Satisfaction of the requirements of the initial stage of the project. The TAC will determine the appropriate initial stage for the project. The project can apply for a different stage via the review process. | ||
| * Projects must find a TAC Sponsor to champion the project and provide mentorship as needed. |
There was a problem hiding this comment.
I'd recommend the first point is to submit the project proposal to wherever the TAC designates.
| * For new projects, a Project Proposal must be submitted (as defined above). | ||
| * Existing projects must request to be considered for the Incubation Stage. | ||
| * Demonstrated adoption (as defined above) by at least one end user, commercial entity, or open-source project is encouraged but not required. |
There was a problem hiding this comment.
There is really nothing different between this and Sandbox. I'd recommend putting some more rigor here.
| * For new projects, a Project Proposal must be submitted (as defined above). | ||
| * Existing projects must request to be considered for the Growth Stage. | ||
| * Demonstrated adoption (as defined above) by at least one end user, commercial entity, or open-source project, indicating the project is beyond the early stage. | ||
| * The project has at least three active maintainers from at least two different organizations. |
There was a problem hiding this comment.
Again - very little rigor here. Maybe it might make sense to align with the OpenSSF Best Practice badge, which would add some rigor and align with other foundations?
| * For new projects, a Project Proposal must be submitted (as defined above). | ||
| * Existing projects must request to be considered for the Graduated Stage. | ||
| * Demonstrated adoption (as defined above) by multiple end users, commercial entities, or open-source projects, indicating the project has achieved significant traction. | ||
| * The project has at least six active maintainers from at least two different organizations. | ||
| * No single organization holds a majority of TSC seats. | ||
| _Exception:_ if a single organization holds more than 1/2 and no more than 2/3 of TSC seats, the TAC may grant a grace period of up to 12 months, provided the project has a clear plan to achieve compliance with the above requirement. |
There was a problem hiding this comment.
I'd recommend more rigor here - maybe OpenSSF Best Practices Gold badge?
|
@OrlinVasilev's comments in today's community call regarding project community infrastucture ( contributing guidelines, release methology, security guidelines ) are great things to have in the lifecycle that I don't see there. The OpenSSF Best Practices badge is a great framework here, and incorporating into the lifecycle would add solid rigor and align with the goals of project maturity consistency. |
|
My idea was also to add them on foundation level and to be able to tune them on way! :) |
|
Hey @OrlinVasilev - what are you meaning by "add them on foundation level"? |
3 participants
This PR introduces an updated, complete lifecycle policy document.
It consolidates ideas from related PRs, review comments, and prior discussions. It bases stage assignment and progression primarily on the size and diversity of the project’s community and the level of project adoption.