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 35 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 (formerly 'Sandbox')

Definition

At Large projects are projects which the TAC believes are, or have the potential to be, important to the ecosystem of Top-Level Projects or the Edge ecosystem as a whole. They may be early-stage projects just getting started, or they may be long-established projects with minimal resource needs. The At Large stage provides a beneficial, neutral home for these projects in order to foster collaborative development and provide a path to deeper alignment with other Foundation projects 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.

Acceptance Criteria

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

  • 2 TAC sponsors (as defined below) to champion the project & provide mentorship as needed
  • A presentation at an upcoming meeting of the TAC, in accordance with the project proposal requirements
  • 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 their status prominently on website/readme
  • 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.

At Large Stage Projects

  • 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


Stage 2: Growth Stage (formerly 'Incubating')

Definition

The Growth Stage is for projects that are interested in reaching the Impact Stage, and have identified a growth plan for doing so. 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 needed.

Acceptance Criteria

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

  • 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, interoperability, compatibility or extension to other LF Edge Projects. Examples may include demonstrating modularity (ability to swap in components between projects).
  • Be onboarded with LFX Security
  • Since 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 criteria.
  • 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 (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 large, well-established project communities with a number of contributors from at least two organizations.

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

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. They receive ongoing financial and marketing support from the Foundation, and are expected to cross promote the foundation along with their activities.

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.

  • Have a security policy and provide a limited-access email address for reporting security vulnerability

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