Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 38 Next »

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 open-source efforts which the TAC believes are, or have the potential to be, important to the edge ecosystem as a whole. They are typically early-stage 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 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 maturity via the graduation process. 

  • 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 that champion the project and volunteer to  mentor the project as needed

  • 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.

  • List their status prominently on website/readme upon acceptance.

  • Receive a two-thirds vote of all 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.


Stage 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 is 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 a willingness to work with (via interoperability, compatibility or extension) other LF Edge projects to provide a greater edge solution than what can be done by the project alone. 
  • Onboard all project repositories with LFX Security.   Working toward or achieving OpenSSF badging would be a plus.
  • Receive a two-thirds vote of all 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

Definition

The Impact Stage is for projects on a self-sustaining cycle of development, maintenance, and long-term support. Impact Stage projects are widely used in production environments with a significant number of public use cases. Moreover they have broad, well-established communities with a number of diverse contributors.

Examples

  1. Projects that have publicly documented release cycles and plans for LTS.
  2. Projects that have themselves become platforms for other projects.
  3. Projects that are able to attract a healthy number of committers on the basis of its production usefulness (not simply 'developer popularity').
  4. Projects that have several, publicly known, end-user deployments.

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.

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).
  • 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 which at a minimum includes meeting ("Met" or "?") all OpenSSF best practices security questions and SECURITY.md.
  • Demonstrate evidence of interoperability, compatibility or extension to other LF Edge Projects. 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).
  • Receive a two-thirds vote of all 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)


  • No labels