Page Comparison

Stages - Definitions & Expectations

Every Foundation project has an associated maturity level, as voted on under the approved Project Lifecycle Document (PLD) process. Proposed Foundation projects should state their preferred maturity level. Projects of all maturities have access to Foundation resources.

All Foundation projects may attend TAC meetings and contribute work regardless of their stage.

Voting Procedures Applicable to All Stages:

All votes to accept/advance Projects will be taken by email over the respective mail lists (e.g. TAC, SPC.) Email vote by the entire TAC obviates the need for quorum. Votes are immutable once cast. Voting threshold numbers are always rounded up to the nearest whole number.

Voting Window:

PLD voting shall be time bound. Once a motion is made and seconded there will be a maximum of 14 calendar days for a vote to occur, with the starting time marked at the day and time a motion is seconded. A vote will cease once a decision point is reached or at the 14 calendar day mark. The voting window applies to both the TAC and Governing Board/Strategic Planning Committee votes, with each having their own independent two week voting period.

Stage 1: At Large Projects

Definition

At Large projects are projects open-source efforts which the TAC believes are, or have the potential to be, important to the ecosystem of Top-Level Projects or the Edge ecosystem edge ecosystem as a whole. They may be are typically early-stage projects just getting started, or they may be long-established projects with minimal resource needs. efforts looking to add capabilities to the LF Edge open edge platform as a whole in exchange for community support.

Expectations of the project

All projects enter LF Edge at the At Large stage, regardless of size, experience, or maturity.  Those that are well-established may graduate to other stages at will, subject to TAC approval.

At Large stage does not set minimum requirements for community size, governance, or production readiness. Projects will be reviewed by the TAC on an annual basis; projects may also request a status review by submitting a report to the TAC.  The TAC may also recommend that a project consider applying for promotion to another stage when they are deemed ready.

Benefits to the project

The At Large stage provides a beneficial, neutral home for these projects in order to foster collaborative development, work towards an open edge framework by collaborating with other LF Edge projects,  and provide a path to deeper alignment with other Foundation projects maturity via the graduation process.

Examples

1. New projects that are designed to extend one or more Foundation projects with functionality or interoperability libraries.
2. Independent projects that fit the Foundation mission and provide potential for a novel approach to existing functional areas (or are an attempt to meet an unfulfilled need).
3. Projects commissioned or sanctioned by the Foundation.
4. Any project that realistically intends to join the Foundation Growth or Impact Level Stages in the future and wishes to lay the foundations for that transition.

Expectations

End users should evaluate At Large projects with care, as this stage does not set requirements for community size, governance, or production readiness. At Large projects will receive minimal marketing support from the Foundation. Projects will be reviewed on an annual basis; they may also request a status review by submitting a report to the TAC 

• Projects will receive marketing support from the Linux Foundation.  This includes being listed as an At Large project on the LF Edge website.
• Projects will receive some tooling and infrastructure assistance (i.e., code repositories, build environments, document sharing / content management services, messaging services, etc. as minimally provided) from the Linux Foundation.  Note: At Large projects are expected to have sponsors that cover expenses outside of what the Linux Foundation and LF Edge can provide or afford.
• Projects will receive mentorship in areas such as but not limited to project management, governance, marketing, tooling, security best practices, and documentation from the other LF Edge projects as well as the Linux Foundation.
• Projects will receive the opportunity to participate in joint demonstrations, proofs-of-concept, and reference-architecture efforts with other LF Edge projects.  Note: At Large projects will be given lowest priority for trade show / event demo showcases in LF Edge booth space.  At Large projects are not expected to lead but can and are encouraged to contribute.

Acceptance Criteria

To be considered for the At Large Stage, the project must meet the following requirements:

• Have at least one LF Edge Member company participating and sponsoring (covering incidental expenses).

• 2 TAC sponsors

  (as defined below) to

  that champion the project

  & provide mentorship

  and volunteer to  mentor the project as needed

• A presentation

  Present their application proposal at an upcoming meeting of the TAC, in accordance with the project proposal requirements

• Have a leadership team of one or more persons and a list of current participants.

• Have a compatible IP policy in place, or work to convert to one before acceptance. The typical IP Policy for Projects under the LF Edge Foundation is Apache 2.0 for Code Contributions, Developer Certificate of Origin (DCO) for new inbound contributions, and Creative Commons Attribution 4.0 International License for Documentation. Projects under outside licenses may still submit for consideration, subject to review/approval of the TAC and Board.

• Upon acceptance, At Large projects must list

  List their status prominently on website/readme upon acceptance.

• Receive a two-thirds vote of all

  TAC representatives

  TAC representatives that do not abstain the vote and a majority vote of the Governing Board's Strategic Planning Committee to enter into the At Large Stage.

At Large

Stage

• Will be listed as such on the LF Edge website
• Will have minimal access to LF Edge funding/resources. Outside of basic code hosting, the sponsoring company should not expect expenses will be covered by LF Edge.
• Will have lowest priority for trade show / event demo showcases in LF Edge booth space

2: Growth Stage

Definition

The Growth Stage is for projects that are interested in reaching the Impact Stage, and have identified a growth plan for doing so. The Growth Stage projects will receive mentorship from the TAC and are expected to actively develop their community of contributors, governance, project documentation, and other variables identified in the growth plan that factor in to broad success and adoption.

In order to support their active development, projects in the Growth stage have a higher level of access to marketing and other resources, which will be agreed upon and reviewed on a yearly basis by the TAC and then the Governing Board. A project's progress toward its growth plan goals will be reviewed on a yearly basis, and the TAC may ask the project to move to the At Large stage if progress on the plan drops off or stalls.

Examples

1. Projects that are on their way or very likely to become Impact Stage  Projects.
2. Projects that have developed new growth targets or other community metrics for success.
3. Projects that are looking to create a lifecycle plan (maintainership succession, contributor programs, version planning, etc.)
4. Projects that need more active support from the Foundation in the form of marketing or TAC mentorship in order to reach their goals.

Expectations

Projects in the Growth Stage are generally expected to move out of the Growth stage within two years. Depending on their growth plans, projects may cycle through At Large, Growth, or Impact stage as neededis meant to harbor projects still working on their product or service and are working towards supporting adopters at scale using the product or service (examples: releasing a bug fix, having to provide guidance on upgrades, addressing a security issue, etc.).

Expectations of the project

Growth Stage projects have well-formed and documented processes, procedures and practices for planning, designing, implementing and documenting their intended edge product or service (while these can always be improved, the project functions in a manner most would say is consistent with modern engineering efforts).  Growth Stage projects are regularly releasing their product or service artifacts – even if they are in early prototypical form, but not yet having to support existing product/service.  Growth Stage projects have the resources (leadership, people, tools, infrastructure) necessary to deliver their product or service.

Benefits to the project

The Growth stage projects are on the cusp of providing, hopefully, a product or service that is widely adopted.  As such, they are provided all the infrastructure and tooling the LF Edge community can reasonably provide in its budget.

Acceptance Criteria

To be considered for Growth Stage, the project must meet the At Large requirements as well as the following:

• Demonstrate regular project leadership (typically TSC) meetings.  Project leadership should meet monthly at a minimum unless there are extenuating circumstances (ex: holiday period).
• Development of a growth plan (to include both roadmap of projected feature sets as well as overall community growth/project maturity), to be done in conjunction with their project mentor(s) at the TAC.
• Document that it is being used in POCs.
• Demonstrate a substantial ongoing flow of commits and merged contributions.
• Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan.
• Demonstrate evidence of, or a plan for, a willingness to work with (via interoperability, compatibility or extension to ) other LF Edge Projects. Examples may include demonstrating modularity (ability to swap in components between projects).projects to provide a greater edge solution than what can be done by the project alone. 
• Onboard all project repositories with LFX SecuritySince these metrics can vary significantly depending on the type, scope and size of a project, the TAC has final judgement over the level of activity that is adequate to meet these criteriarepositories with LFX Security.   Working toward or achieving OpenSSF badging would be a plus.
• Receive a two-thirds vote of all TAC representatives TAC representatives that do not abstain the vote and a majority vote of the Governing Board to move to Growth Stage.

Stage 3: Impact Stage (formerly 'Top-Level')

Definition

The Impact Stage is for projects that have reached their growth goals and are now on a self-sustaining cycle of development, maintenance, and long-term support. Impact Stage projects are widely used in production environments and have largewith a significant number of public use cases. Moreover they have broad, well-established project communities with a number of contributors from at least two organizations.Examplesdiverse contributors.

Expectations of the project

• Are used in production environments. 
• Impact Stage projects are expected to participate actively in TAC proceedings, and as such have a binding vote on TAC matters requiring a formal vote, such as the election of a TAC Chair. 
• Projects that have publicly documented release cycles

• .
• Projects that

• are able to attract a

• number of committers on the basis of its production usefulness

• .

• Projects that have several, publicly known, end-user deployments.

Expectations

Impact Stage projects are expected to participate actively in TAC proceedings, and as such have a binding vote on TAC matters requiring a formal vote, such as the election of a TAC Chair. Benefits to the project

They receive ongoing financial and marketing support from the Foundation, and are expected to cross promote the foundation along with their activities.

• Annual discretionary budget

Acceptance Criteria

To graduate from At Large or Growth status a project must meet the Growth stage criteria plus:

• 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 a documented and publicly accessible description of the project's governance, decision-making, and release processes.
• Have a healthy number of committers from at least two organizations. A committer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project.
• Establish a security and vulnerability process vulnerability process which at a minimum includes meeting ("Met" or "?") all all OpenSSF best practices security questionsand SECURITY. md.
• Demonstrate evidence of interoperability, compatibility or extension to other LF Edge Projects.  Examples Examples may include demonstrating modularity (ability to swap in components between projects).
• Adopt the Foundation Code of Conduct.
• Explicitly define a project governance and committer process. This is preferably laid out in a GOVERNANCE.md file and references a CONTRIBUTING.md and OWNERS.md file showing the current and emeritus committers.
• Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website).
• Other metrics as defined by the applying Project during the application process in cooperation with the TAC.
• Receive a two-thirds vote of all TAC representatives TAC representatives that do not abstain the vote and a majority vote of the Governing Board to move to Impact stage. Projects can move directly from At Large to Impact, if they can demonstrate sufficient maturity and have met all requirements.

Stage 4: Emeritus Stage

Definition

Emeritus projects are projects which the maintainers feel have reached or are nearing end-of-life. Emeritus projects have contributed to the ecosystem, but are not necessarily recommended for modern development as there may be more actively maintained choices. The Foundation appreciates the contributions of these projects and their communities, and the role they have played in moving the ecosystem forward.

Examples

1. Projects that are "complete" by the maintainers' standards.
2. Projects that do not plan to release major versions in the future.

Expectations

Projects in this stage are not in active development. Their maintainers may infrequently monitor their repositories, and may only push updates to address security issues, if at all. Emeritus projects should clearly state their status and what any user or contributor should expect in terms of response or support. If there is an alternative project the maintainers recommend, it should be listed as well. The foundation will continue to hold the IP and any trademarks and domains, but the project does not draw on foundation resources.

Acceptance Criteria

Projects may be granted Emeritus status via a two-thirds vote of all TAC representatives that do not abstain the vote and a majority vote of the Governing Board and with approval from project ownership. In cases where there is a lack of project ownership, only a two-thirds vote from the TAC is required.

Annual Review Process

The TAC shall develop an annual review process to determine whether projects are in the stage that accurately reflects their needs and goals. If a project is determined to be out of place, the TAC shall provide guidance to the project in the form of recommendations towards resolving the situation.

Definitions

TAC Sponsor:  TAC Sponsors are voting TAC members who act as a voice of the TAC to shepherd a proposed project through the process. TAC Sponsors are expected to have some knowledge in the ‘Proposed Projects code’ (at a reasonable level, be able to speak and answer questions on behalf of the proposal). If not identified in initial Proposal, a TAC Sponsor is a volunteer (or volunteers) from the TAC who believe the Proposed Project might be a good fit in the LF Edge Foundation, and agrees to support the project (technical and/or marketing contributions). At least one TAC Sponsor should come from a non-applying TAC member.

Standard Voting Options:

• Yes: In favor of the motion
• No: Against a motion that has been risen
• Abstention: Neither in favor or against. Impact - Reduces voting pool
• No vote cast: No vote cast by Primary or Alternate TAC voting member during the voting window. Impact - None. Does not impact the number of votes needed to pass a motion.

Abstention: A vote cast to abstain shall not have any impact in the positive/yes/+1 nor negative/no/-1 direction of a voting process. An abstention is treated as a neutral “don’t care” zero and will reduce the voting pool to which the passage criteria is applied.

• Example A: 32 eligible TAC voters. 3 abstain from a vote. The voting pool is reduced to 29. To pass a two-thirds vote, you would then need 20 votes in favor to advance the motion (32-3 = 29 x 2/3 = 19.333 = 20) not the original 22. (32 x 2/3 = 21.333 = 22)
• Example B: 25 eligible Board voters. 4 abstain from a vote. The voting pool is reduced to 21. To pass a majority vote you would need 11 votes in favor to advance the motion (25-4 = 21 x 1/2 = 10.5 = 11) not the original 13. (25 x 1/2 = 12.5 = 13)