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"? |
| ## 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
There was a problem hiding this comment.
I would prefer if this would be a unified process. Otherwise, it may appear intransparent to outsiders as it may not be obvious who takes a decision where. This is certainly no showstopper, though.
There was a problem hiding this comment.
Hi @ScheererJ - to give context on how other projects look at this, the TAC and GB have different roles in approving a lifecycle.
- TAC - Focus is on the technical aspects, ensuring the TAC has a good way to gauge the health of projects and ability to nurture them to growth.
- GB - Focus is on fiduary support ( i.e., ensuring the foundation has the resources to support what is in the lifecycle ) and confirming that the lifecycle aligns with the mission in the DF charter.
In practice, the TAC tends to be the more active body in maintaining the project lifecycle, as most of the lifecycle aligns back to project growth aspects. Rarely do changes originate in the GB, and those cases line back up to a fiduary/budget concern, or DF charter alignment.
The LF staff manages this same relationship across the many other projects with the same umbrella structure, and we can help advise the TAC and GB as it goes through any lifecycle change processes.
Let me know if this is helpful!
There was a problem hiding this comment.
Sure, I agree that they have different roles. As someone opening a PR, I would like to understand what will happen. From my point of view, it would be the easiest if the approval would be visible in the PR.
A link to the voting results would be the next best option.
What I would like to prevent is a situation when PRs are merged at seemingly random points in time and only insiders understand the relation between a change and a corresponding vote.
|
|
||
| * 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) |
| ## 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.
|
|
@fmui can you please start incorporating or integrating these comments or state that youre okay with us modifying the branch? |
5 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.