DO NOT use the confluence section numbering widget on this page as it will mess things up!
Once we have agreement from the TSC I will incorporate the approved edits into the actual Community
Thanks! Kenny Paul 3.3. Project Lifecycle
3.3.1. ONAP Project Lifecycle
The activities of the ONAP community are articulated around projects and releases. The scope of each project is aligned with the ONAP architecture and the scope of each release is defined with the objective to fulfill a particular requirement(s) (use case, functional or non functional).
3.3.1.1. A project is a long term endeavor setup to deliver features across multiple releases, which have a shorter lifespan.
3.3.1.2. The project and release lifecycle are simple and provide sufficient visibility to allow teams to coordinate with one another and flock naturally.
3.3.1.3. The key point of the project and release lifecycle process are to provide adequate visibility to all stakeholders, provide synchronization, and support to all contributors.
3.3.1.4. This document covers the ONAP project lifecycle. The Release Lifecycle is documented in a separate document Release Process.
3.3.2. Project Lifecycle Overview
3.3.2.1. The project lifecycle provides the freedom for each team to conduct its project according to their needs, culture and work habits. Thus, the project lifecycle is not prescriptive on how each project operates.
3.3.2.2. An ONAP release can be composed of 1 to N projects. As such the number of contributing projects to a particular release may vary overtime.
3.3.2.3. A release is initiated to deliver a set of project deliverables.
3.3.2.4. The project lifecycle process does not impose a duration for the project nor for the release. There is an independent Release Plan document for each release to specify release timelines which includes, but is not limited to the following:
3.3.2.5. Release Plan
3.3.2.5.1. Introduction
3.3.2.5.2. Release Deliverables
3.3.2.5.3. Release Milestones
3.3.2.5.4. Expected Dependencies on Other Projects
3.3.2.5.5. Compatibility with Previous Release
3.3.2.5.6. Themes and Priorities
3.3.2.5.7. Other(s)
3.3.2.5.8. Features delivered
3.3.2.5.9. Non-Code Aspects (user docs, examples, tutorials, articles)
3.3.2.5.10. Architectural Issues (if any)
3.3.2.5.11. Security Issues (if any)
3.3.2.5.12. Quality Assurance (test coverage, etc)
3.3.2.5.13. End-of-life (API/Features EOLed in Release)
3.3.2.5.14. Summary of Outstanding Bugs
3.3.2.5.15. Summary of Standards Compliance
3.3.2.5.16. Delta between planned schedule and actual schedule
3.3.2.6. Release Review
The project shall document results of the review in the release notes
3.3.2.6.1. Features delivered
3.3.2.6.2. Non-Code Aspects (user docs, examples, tutorials, articles)
3.3.2.6.3. Architectural Issues (if any)
3.3.2.6.4. Security Issues (if any)
3.3.7.6.5. Quality Assurance (test coverage, etc)
3.3.2.6.6. End-of-life (API/Features EOLed in Release)
3.3.2.6.7. Summary of Outstanding Bugs
3.3.2.6.8. Summary of Standards Compliance
3.3.2.6.9. Delta between planned schedule and actual schedule
3.3.3. Project Lifecycle States and Reviews
ONAP project lifecycle defines six states that each project goes through. The project lifecycle may extend across multiple releases.
The procedure of moving from one state to the next one is independent from the release and the pace depends on each individual project.
In order to effectively review project progress, five reviews are build-in within the project lifecycle.
The lifecycle of a project is depicted on the following diagram:
Project State | Description |
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. |
Incubation | Project has resources, but is recognized to be in the early stages of development. The outcome is a minimum viable product (MVP) that demonstrates the value of the project and is a useful vehicle for collecting feedback, but is not expected to be used in production environments. |
Mature | Project is fully functioning and stable, has achieved successful releases. It should also be noted that Projects in Mature state meet all Global Requirements. |
Core | Project provides value to and receives interest from a broad audience. It should also be noted that Projects in Mature state meet all Global Requirements. |
Archived | Project can reach the Archived state for multiple reasons. Either the project has successfully been completed and its artifacts provide business values, or the project has been cancelled for unforeseen reasons (no value anymore, technical, etc.). Project in any state can be Archived through a Termination Review. |
| Unmaintained |
|
To move from one state to the next state, the Project Team has to formulate a Kick-Off release review to the TSC, by specifying its goal to move up the Project Lifecycle ladder.
From State | To State | Review Description |
Null | Proposal | |
Proposal | Incubation | Incubation review |
Incubation | Mature | Maturity review |
Mature | Core | Core review |
Core | Archived | Termination review |
| Incubation/Mature/Core | Unmaintained | Unmaintained review |
| Unmaintained | Incubation/Mature/Archived | Incubation/Mature/Archived review |
Note 1: Project proposals are posted in the “Proposed Projects” section of the ONAP wiki. Approved projects are posted to the “Approved Projects” section of the ONAP wiki.
Note 2: The proposal submitter can decide to remove projects in “proposal” state that do not progress to incubation state.
3.3.4. Tailoring
A project’s release cycle may be tailored by allowing some exceptions to the normal release process. Tailoring may be initiated in three ways:
3.3.4.1. By the TSC voting members: TSC voting members reserves the right to allow changes to the process in order to meet criteria that were initially unknown.
3.3.4.2. By Project Team Lead: Any project team lead can email TSC voting members to request tailoring the process for a particular release. The key point in tailoring is to anticipate as much as possible, to justify the request, and document the request in the wiki.
3.3.4.3. Tailoring practices will be documented as we progress through our releases. The TSC should respond to requests in a timely manner.
3.3.5. Reviews & Metrics Overview
3.3.5.1. Project promotion across states can only be done by TSC review and voting. During the reviews the candidate projects are evaluated based on predefined metrics and KPIs. The target numbers may vary for each project and state.
3.3.5.1.1. Longevity of the project
3.3.5.1.2. Project follows (or doesn't) the ONAP release cadence
3.3.5.1.3. Requirements have resulted in corresponding implementations
3.3.5.1.4. Comprehensiveness and maturity of the artifacts (code, test cases, documentation) the project produces including contributions/code to partner/upstream projects where applicable
3.3.5.1.5. Mature testing/integration success for defined environments (ONAP and/or partner/upstream projects, which is applicable or both)
3.3.5.1.6. Project artifacts: it is expected that all project’s artifacts are available and accessible to all contributors of the ONAP community. Links toward projects artifacts must be provided
3.3.5.1.7. Community Size and diversity of the active community (number and diversity of people contributing)
3.3.5.2. For each and every review the following steps are required:
3.3.5.2.1. The project review is posted two weeks in advance in the Release Wiki. This allows all contributors to provide feedback prior to the review meeting. (include link when available)
3.3.5.2.2. The project review is emailed to onap-tsc@lists.onap.org mailing list
3.3.5.2.3. Disposition by TSC: Confirm that the project state is complete and the listed requirements are met.
3.3.5.2.4. Simple majority approval by voting TSC members
3.3.5.2.5. Reviews for multiple projects can occur at the same time.
3.3.5.2.6. During Release Kick-Off, the project team may request that the TSC conduct a review to move up the ladder.
3.3.6. Project Reviews
3.3.6.1. Incubation Review
The goal of the Incubation Review is to officially launch the project and to support its needs until project Termination Review.
3.3.6.1.1. Once a project has passed the Incubation Review, the project is in Incubation State and may span over multiple releases.
3.3.6.1.2. Proposal template is available on the ONAP wiki .
3.3.6.1.3. The following artifacts are expected:
3.3.6.1.3.1. Name of the project is appropriate (no trademark issues etc.); Proposed repository name is all lower-case without any special characters
3.3.6.1.3.2. Project contact name, company and email are defined and documented
3.3.6.1.3.3. Description of the project goal and its purpose are defined
3.3.6.1.3.4. Scope and project plan are well defined
3.3.6.1.3.5. Resources committed and available contributors identified
3.3.6.1.3.6. Initial list of Committers identified (elected/proposed by initial contributors)
3.3.6.1.3.7. Meets ONAP TSC Policies
3.3.6.1.3.8. Proposal has been socialized with potentially interested or affected projects and/or parties
3.3.6.1.3.9. Cross Project Dependencies (XPDs). In the case where a project will require changes in other projects, those projects are listed in the proposal, and a sponsoring developer in the project has been identified
3.3.6.1.3.10. 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)
3.3.6.2. Maturity Review
The goal of the Maturity Review is to ensure:
3.3.6.2.1. Artifacts for Incubation State are complete and accepted
3.3.6.2.2. Plan for Maturity State are accepted
3.3.6.2.3. Once a project has passed the Maturity Review, the project is in Mature State and may span over multiple releases.
3.3.6.2.4. Review metrics for Maturity review:
3.3.6.2.4.1. Successful participation in releases: The project demonstrates stable output (code base, documents) within its history of releases in accordance with the release policy.
3.3.6.2.4.2. Architecture has been reviewed by the Architecture Committee
3.3.6.2.4.3. Project is active and contributes to ONAP: The project demonstrates a stable or increasing number of contributions across recent releases. Contributions are commits which got merged to a repository of an ONAP project or a related upstream project. Commits can for example be patches to update the requirements document of a project, code addition to an ONAP or upstream project repository, new test cases and so forth.
3.3.6.2.4.4. 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 end users (typically, service providers).
3.3.6.3. Core Review
The goal of the Core Review is to ensure:
3.3.6.3.1. Artifacts for Maturity State are complete and accepted
3.3.6.3.2. Plan for Core State are accepted. For the Core Review it is expected to deliver a comprehensive integration plan
3.3.6.3.3. Once a project has passed the Core Review, the project is in Core State and may span over multiple releases.
3.3.6.3.4. Review metrics for Core review include the metrics for maturity review plus the following:
3.3.6.3.5. Contributor diversity: The project demonstrates that it has a stable core team of contributors/committers which are affiliated to a set of at least three different companies. Core team members are those who have been active on the project for more than two releases, which means they were reviewing contributions to the project in ONAP Code Review and/or in the review-tool of the target upstream project(s).
3.3.6.3.6. Recognized value through other projects: The project demonstrates that its results are leveraged by other ONAP projects in an ongoing way, i.e. for at least the last two releases.
3.3.6.3.7. Successful integration tests (only applicable to projects which provide features/functionality): The project demonstrates that component tests and system-level tests have been implemented, that tests are used within the ONAP-O CI/CD test pipeline, and that tests bear successful results.
3.3.6.3.8. Stability, Security, Scalability and Performance levels have reached a high bar and are maintained as such for each release.
3.3.6.4. Termination Review ← Pick up the discussion on the specific wording of "termination" here on
A bounded piece of work is complete, no new features are being added, but there are still individuals around to maintain the code for bug and security fixes.
The goal of the Termination Review is to ensure that:
3.3.6.4.1. Artifacts for Core state are complete and accepted
3.3.6.4.2. Core project artifacts are acceptable and meet the acceptance criteria
3.3.6.4.3. Project Team has the confidence that its artifacts can be used outside the ONAP community
3.3.6.4.4. Metrics for Termination review are available
3.3.6.5. Unmaintained Review
An unmaintained review is automatically triggered when bounded piece of work has had no individuals available or willing to contribute or participate in bug or security fixes in at least two releases.
The goal of the Unmaintained Review is to ensure that:
3.3.6.5.1. Project(s) or sub-project(s) is no more longer part of any official release
3.3.6.5.2. These Project(s) or sub-project(s) are no more subject to longer compliant with non-functional compliances, but are still in OOM.
3.3.6.5.3. The project will be still part of OOM deployment and High Priority bugs might be fixed
The process of managing this review state can be found here
3.3.7. Mature Release Process
A Project’s Committers make all decisions about Releases of that Project. However, to be eligible to be considered ‘Mature’, the project must demonstrate a history of following the Mature Release Process. The purpose of the Mature Release Process is to ensure openness and maximum opportunity for participation. The idea is to have a simple, clear, public declaration of what a project intends to do and when, and what was actually done in a release cycle. Towards that end, a project following the ‘Mature Release Process’ should have a Release Plan published at the beginning of its release cycle by its committers, and a Release Review just prior to the project release.
Both Release Plan and Release Review documents are intended to be relatively short, simple, and posted publicly on the wiki to assist the project in coordinating among themselves and the general world in gaining visibility.
These should contain roughly the following sections:
3.3.7.1. Release Plan
3.3.7.1.1. Introduction
3.3.7.1.2. Release Deliverables
3.3.7.1.3. Release Milestones
3.3.7.1.4. Expected Dependencies on Other Projects
3.3.7.1.5. Compatibility with Previous Release
3.3.7.1.6. Themes and Priorities
3.3.7.1.7. Other
3.3.7.1.8. Features delivered
3.3.7.1.9. Non-Code Aspects (user docs, examples, tutorials, articles)
3.3.7.1.10. Architectural Issues (if any)
3.3.7.1.11. Security Issues (if any)
3.3.7.1.12. Quality Assurance (test coverage, etc)
3.3.7.1.13. End-of-life (API/Features EOLed in Release)
3.3.7.1.14. Summary of Outstanding Bugs
3.3.7.1.15. Summary of Standards Compliance
3.3.7.1.16. Delta between planned schedule and actual schedule
3.3.7.2. Release Review
3.3.7.2.1. Features delivered
3.3.7.2.2. Non-Code Aspects (user docs, examples, tutorials, articles)\
3.3.7.2.3. Architectural Issues (if any)
3.3.7.2.4. Security Issues (if any)
3.3.7.2.5. Quality Assurance (test coverage, etc)
3.3.7.2.6. End-of-life (API/Features EOLed in Release)
3.3.7.2.7. Summary of Outstanding Bugs
3.3.7.2.8. Summary of Standards Compliance
3.3.7.2.9. Delta between planned schedule and actual schedule
2 Comments
Amy Zwarico
I recommend adding that Mature and Core projects meet all Global Requirements.
Thomas Kulik
This page describes the project lifecycle quite good. Most projects contain multiple repositories. I recommend to describe also the relation between projects and repositories and especially whether/how repos derive the state from the project. Do all of the repos get the same (derived) state? Where do we want to store the state information for the project and the repos? (INFO.yaml?, per project?, per repo?, page in DevWiki? git repo state ACTIVE/READ_ONLY, ...). Unfortunately currently we have all of it and it is not handled in a consistent way). And how does the project/repo state relate to what is deployed via OOM?