toc/PROJECT_LIFECYCLE.md

I. Overview

This governance policy describes how an open source project can formally join the foundation via the Project Lifecycle Process defined in this document. It describes the Stages a project may be admitted under and what the criteria and expectations are for a given stage, as well as the acceptance criteria for a project to move 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 projects benefit from a deepened alignment with existing projects, and access to mentorship, support, and foundation resources.

II. Project Lifecycle Process

Introduction

This governance policy sets forth the proposal process for projects to be accepted into the foundation. The process is the same for both existing projects which seek to move into the Foundation and new projects to be formed within the Foundation.

Every project will start at incubation and can progress toward graduation on its own timeline.

Submitting proposals

Projects must be formally proposed via GitHub by submitting a pull request to this repository. See the Project Proposals directory for the previous proposals and the template.

Project Proposal Requirements

Project proposals submitted should provide the following information to the best of their ability:

• name of project
• project description (what it does, why it is valuable, origin and history)
• statement on alignment with foundation charter's mission
• link to current Code of Conduct (if one is adopted already)
• sponsor from TOC, if identified (a sponsor helps mentor projects)
• project license
• source control (GitHub by default)
• issue tracker (GitHub by default)
• external dependencies (including licenses)
• release methodology and mechanics
• names of initial committers, if different from those submitting proposal
• briefly describe the project's leadership team and decision-making process
• link to any documented governance practices
• preferred maturity level (see Stages below)
• list of project's official communication channels (slack, irc, mailing lists)
• link to project's website
• links to social media accounts
• existing financial sponsorship
• infrastructure needs or requests

Project Acceptance Process

• Projects are required to present their proposal at a TOC meeting
• The TOC may ask for changes to bring the project into better alignment with the 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 via a 2/3 supermajority vote of the TOC.
• The proposal document will be finalized as a project charter. This charter document must be included in the project's main repository.
• The TOC will determine the appropriate initial stage for the project. The project can apply for a different stage via the review process.

III. Stages - Definitions & Expectations

Every project has an associated maturity level. Proposed projects should state their preferred maturity level.

Representatives from all projects may attend TOC meetings and contribute work regardless of their stage.

Incubation Stage

Definition

The Incubation Stage is for projects that are interested in reaching broad adoption and have identified a growth plan for doing so. Incubation Stage projects will receive mentorship from the TOC 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.

A project's progress toward its growth plan goals will be reviewed on a yearly basis.

Examples

1. Projects that have developed new growth targets or other community metrics for success.
2. Projects that are looking to create a lifecycle plan (maintainership succession, contributor programs, version planning, etc.)
3. Projects that need more active support from the Foundation or TOC mentorship in order to reach their goals.

Expectations

Projects in the Incubation Stage are generally expected to move out of the Incubation stage over time. Depending on their growth plans, projects may cycle through Incubation or Graduation stage as needed.

Acceptance Criteria

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

• 2 TOC sponsors to champion the project and provide mentorship as needed
• A presentation at a meeting of the TOC
• Adherence to the foundation's IP Policy
• Upon acceptance, At Large projects must list their status prominently on their website/README
• Development of a growth plan, to be done in conjunction with their project mentor(s) at the TOC.
• Document that it is being used successfully in production by at least two independent end users which, in the TOC’s judgement, are of adequate quality and scope.
• 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.
• Since these metrics can vary significantly depending on the type, scope and size of a project, the TOC has final judgement over the level of activity that is adequate to meet these criteria.
• Receive a two-thirds supermajority vote of the TOC to move to Incubation Stage.

Graduated Stage

Definition

The Graduated Stage is for projects that have reached their growth goals and are now on a sustaining cycle of development, maintenance, and long-term support. Graduated Stage projects are used commonly in enterprise production environments and have large, well-established project communities.

Examples

1. Projects that have publicly documented release cycles and plans for Long Term Support ("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, high-profile or well known end-user implementations.

Expectations

Graduated Stage projects are expected to participate actively in TOC proceedings. 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 Incubating status, a project must meet the Incubation stage criteria plus:

• Have a defined governing body which consists of members from at least 2 different companies.
• 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.
• 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 TOC.
• Have achieved and maintained a OpenSSF Best Practices Badge.
• Receive a 2/3 supermajority vote from the TOC to move to Graduated stage.

Emeritus Stage (Archive)

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 2/3 vote from the TOC.

IV. Annual Review Process

The TOC shall develop an annual review process to determine whether projects are in the stage that accurately reflects their needs and goals.