State

Description

Release Quality

Release Numbering

Deliverables / Exit Criteria

Proposal

Project doesn’t really exist yet, may not have real resources, but is proposed and is expected to be created due to business needs.

n/a

n/a

From 3.3.7.1 Incubation Review:

-    Name of the project is appropriate (no trademark issues etc.); Proposed repository name is all lower-case without any special characters [a checkmark]

-    Project contact name, company and email are defined and documented [presumably at least one proposer]

-    Description of the project goal and its purpose are defined [a checkmark – use the templates]

-    Scope and project plan are well defined [yes to scope, no to project plan]

-    Resources committed and available

-    Contributors identified

-    Initial list of committers identified (elected/proposed by initial contributors)

-    Meets Akraino TSC Policies [need to define what these are? – Bill to find out what these are – Jenny’s chasing down some language about this]

-    Proposal has been socialized with potentially interested or affected projects and/or parties (e.g. presented at Community Meeting)

-    Cross Project Dependencies (XPDs). In the case where a project will require changes in other projects and upstream dependencies, those projects are listed in the proposal, and a sponsoring developer in the project has been identified

-       Tools have been identified and discussed with relevant partners (Linux Foundation, IT). Once the project passes the review, the tools chain must be created within one week. Tools encompass Configuration Management, CI/CD, Code Review, Testing, Team Wiki, End Users documentation (not exhaustive).

Incubation

Project has resources, but is recognized to be in the early stages of development.

Alpha (MVP) à Beta

0.1 à 0.x

From 3.3.7.2 Maturity Review:

-       PTL & Committers are in place.

-    Beta-Quality Release Achieved [we need to double-click on what the definition of Beta quality is – FOA, POC, end of release?] – this is signified by having 2 adopters willing to

-    Successful participation in at least two releases (which signifies that the BP is at Beta quality): The project demonstrates stable output (code base, documents) within its history of releases in accordance with the release policy. [this implies that nothing will be Mature in Rel 1 – TSC should confirm that’s what they want]

-    Architecture has been reviewed by the CI/CD Sub-Committee, TSC and presented to broader Akraino community [why have the CI/CD Sub-Committee review the architecture – the next point should cover this]

-    Project Contributors have provided a validation lab [should be 2 labs] with exact configuration required by the project to connect with Akraino CI and demonstrate CD. The environment should be reviewed and endorsed by the CI/CD Sub-Committee.

-    Acceptance Tests: who & when do we validate the acceptance tests for the BP?

-    Project is active and contributes to Akraino: The project demonstrates increasing number of commits and/or number of contributions across recent releases. Contributions are commits that have been to an Akraino repository project or related upstream project. Commit examples can be patches to update the requirements document of a project, code addition to an Akraino or upstream project repository, new test cases and so forth. [maybe create a template, or use something like Bitergia to get some consistent metrics coming into this review]

-       Mature artifacts produced: The project demonstrates that the artifacts produced by the project are deployable (where applicable) and have been successfully deployed, configured and used by at least two independent end users typically, service providers who have publicly documented their support on the Akraino wiki and within the accompanying project documentation. [considering moving this to Mature, since it’s quite deterministic, and consider adding a point here that the project needs to state how many independent deployments it has]