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.
There was a problem hiding this comment.
Agreed. It is difficult to distinguish both stages if there are no additional requirements.
| * 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"? |
| # NeoNephos Foundation Project Lifecycle Policy | ||
|
|
||
| Version 2, January 2026 | ||
| Version 2, June 2026 |
There was a problem hiding this comment.
Nit: Not sure what the date represents, but I have doubts that this will be merged in June.
There was a problem hiding this comment.
I think version is just enough the rest of the meta-data is in Github
| ## Policy Revision Process | ||
|
|
||
| Revisions to the NeoNephos Foundation Project Lifecycle Policy can be initiated by any member of the Technical Advisory Council (TAC) or the Governing Board. Proposed changes should be documented and circulated among both groups for review and discussion. To enact a revision, a simple majority vote of both the TAC and the Governing Board is required, ensuring collaborative oversight and consensus. | ||
| Revisions to the NeoNephos Foundation Project Lifecycle Policy (the "Policy") can be initiated by any member of the Technical Advisory Council (TAC) or the Governing Board of the NeoNephos Foundation (the "Foundation"). Proposed changes should be documented and circulated among both the TAC and the Governing Board for review and discussion. To enact a revision, a simple majority vote of both the TAC and the Governing Board is required, ensuring collaborative oversight and consensus. |
There was a problem hiding this comment.
Just a process question as the document is changed via PRs. Is the vote handled as part of the PR via approvals or is there any link how to get from PR to voting results? It seems good in theory, but in reality this should not be two separate processes from my point of view.
There was a problem hiding this comment.
we can do voting via the https://projectadmin.lfx.linuxfoundation.org
| This governance policy describes how an open-source project can formally join the NeoNephos Foundation via the Project Proposal Process. It describes the Stages a project may be admitted under, the criteria and expectations for each stage, and the Acceptance Criteria for progressing from one stage to another. It also describes the Annual Review Process through which those changes will be evaluated and made. | ||
|
|
||
| Project progression - movement from one stage to another - allows projects to participate at the level that is most appropriate for them given where they are in their lifecycle. Regardless of stage, all NeoNephos Foundation projects benefit from a deepened alignment with existing projects, and access to mentorship, support, and foundation resources. | ||
| Project progression — the movement from one stage to another — allows projects to participate at the level that is most appropriate for them given where they are in their lifecycle. Regardless of stage, all NeoNephos Foundation projects benefit from closer alignment with existing projects, and from access to mentorship, support, and Foundation resources. |
There was a problem hiding this comment.
Is it really necessary to use em dashes? Usually, they are a sign of AI use. It will most likely reflect bad on the TAC if people assume the policy is AI generated.
|
|
||
| * Project name | ||
| * Project description (what it does, why it is valuable, origin and history) | ||
| * List of adopters, case studies, or testimonials (if any) |
There was a problem hiding this comment.
From my point of view, this is a purely optional requirement. Therefore, it should also be marked as optional. if any suggests that you only need to provide it if they exist, but in reality open source projects may not even be aware of adopters, which is also completely fine. Some adopters do not what to appear on a list of adopters.
| * List of adopters, case studies, or testimonials (if any) | |
| * List of adopters, case studies, or testimonials (optional) |
| * List of the project’s official communication channels (Slack, IRC, mailing lists) | ||
| * List of the project's official communication channels (Slack, Discord, Matrix, mailing lists, etc.) |
There was a problem hiding this comment.
Does it make sense to add zulip as NeoNephos uses it anyway?
| ## Policy Revision Process | ||
|
|
||
| Revisions to the NeoNephos Foundation Project Lifecycle Policy can be initiated by any member of the Technical Advisory Council (TAC) or the Governing Board. Proposed changes should be documented and circulated among both groups for review and discussion. To enact a revision, a simple majority vote of both the TAC and the Governing Board is required, ensuring collaborative oversight and consensus. | ||
| Revisions to the NeoNephos Foundation Project Lifecycle Policy (the "Policy") can be initiated by any member of the Technical Advisory Council (TAC) or the Governing Board of the NeoNephos Foundation (the "Foundation"). Proposed changes should be documented and circulated among both the TAC and the Governing Board for review and discussion. To enact a revision, a simple majority vote of both the TAC and the Governing Board is required, ensuring collaborative oversight and consensus. |
There was a problem hiding this comment.
Does this mean that someone who is not part of the TAC or the governing board cannot propose changes? For sure, external contributions have a lower weight than internal ones, but this more or less states that external contributions to this document are not possible at all. Is this really what we want?
| ##### Expectations | ||
|
|
||
| A project can remain a Sandbox project for a maximum of one year. Sandbox projects are experimental and their output is not intended to be used in production. Projects that release production-ready artifacts should transition to a more mature stage. | ||
| Projects should remain in the Sandbox Stage for no more than one year, unless the TAC grants an extension. Sandbox projects are experimental, and their outputs are not intended for production use. Projects that release production-ready artifacts should transition to a more mature stage. Projects that do not progress may be moved to the Emeritus Stage. |
There was a problem hiding this comment.
Can the TAC provide unlimited extensions? This paragraph is fairly vague about it. It feels like the TAC can do whatever it wants.
Not sure if we want to explicitly document a maximum limit, e.g. 3 years.
WDYT?
| * 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.
Agreed. It is difficult to distinguish both stages if there are no additional requirements.
|
|
||
| After the review, to be accepted at the Incubation Stage, the project must receive a simple majority of the TAC. | ||
| * The project must submit a request to the TAC for consideration to move to Incubation Stage. | ||
| * The TAC will consider this request in an upcoming TAC meeting after the TAC has had sufficient time to review the request. The TAC may request that the project present at an upcoming TAC meeting, outlining how the project has satisfied the Acceptance Criteria described above. |
There was a problem hiding this comment.
Not really sure, how you would demonstrate the requirements above. Could you please explain?
| ##### Examples | ||
|
|
||
| * Projects that have publicly documented release cycles and plans for Long Term Support ("LTS"). | ||
| * Projects that have publicly documented release cycles and plans for Long-Term Support ("LTS"). |
There was a problem hiding this comment.
What does long-term support mean? For example, would the kubernetes project count as having long-term support even if it only supports the last three release, which boils down to little over a year (14 months). From enterprise point of view, that might not be long. For an open source project it is.
Do we want to make this more tangible?
|
After reading it I think we can improve on:
Sorry if this is overkill just observations :) |
|
Hey @OrlinVasilev - generally +1 all of this, a few comments.
|
4 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.