...
Technical and release decisions for a project should be made by consensus of that the project’s Committers. If consensus cannot be reached, decisions are taken by majority vote of a project’s Committers. Committers may, by majority vote, delegate (or revoke delegation) of any portion of such decisions to an alternate open, documented, and traceable decision-making process.
...
- Code type: major delivery of a code-type project is code and document. It has one or a group of related functions functional codes (considering donators’ opinion). Projects targeting on integrations are considered code-type as well.
- Doc type: major delivery of a doc-type project is only document. Mostly requirement doc, architecture doc for the entire platform or a group of platform users.
2.3.3. Project Lifecycle
...
The lifecycle of a project is depicted on the following diagram:
...
For XGVela projects, it means internal projects under XGVela community. It follows the following lifecycle procedure.
Highlights:
| Project State | State Summary |
|---|---|
| none | Project does not exist or exists outside of XGVela. |
| Aprroved | Project is reviewed and admitted to XGVela. A team who wants to establish a new project under XGVela should follow Project Proposals guide. |
| Archived | Project is no longer active. |
2.4. Project Review
XGVela follows the LFN Project Lifecycle process which includes the Project Review Process, and can be found here: LFN Project Lifecycle
To move from one state to the next state, the Project Team has to propose to TSCs about their moving-up goals, project data, and request for formal review discussion. TSC will vote on project state change.
...
2.4. Project Review
2.4.1. Review Progress
For all reviews, the following steps are required:
- The project review request and review materials are posted to XGVela-project-lifecycle Confluence (under creation).
- The project review is emailed to https://lists.xgvela.org/g/main mailing list.
- Present state-changing proposal on TSC meeting and get vote by TSC members (usually more than half of attending TSC voted means approval).
2.4.2. Review Contents
2.4.2.1. Incubation Review The goal of Incubation Review is to officially launch the project as XGVela project and to support its needs until project Termination Review.
Once a project has passed the Incubation Review, the project is in Incubation State and may span over multiple releases.
To apply entering Incubation state, the following contents are required:
- Name of the project: (appropriate, no trademark issues etc.)
- Repository name: (lower-case without any special characters)
- Project contact: (name, company, email)
- Initial committer list: (name, company, email)
- Contributor list: (name, company, email)
- Meets XGVela TSC policy
- Project goal and purpose
- Project functionality and major usage scenarios: (for code-type project, explain functionality of code, under what scenario the project should provide service; for doc-type project, explain brief document direction and using scenarios)
- Project relationship with General PaaS/ Adaptation Layer/ Telco PaaS: (used which General PaaS functions, this project functionality should be located in adaptation layer or telco PaaS)
- Relationship with other projects
- Project scope
- Project release plan: (plan for at least two releases)
- Tools required
2.4.2.2. Maturity Review
The goal of Maturity Review is to ensure:
- Artifacts for Incubation State are completed and accepted
- Project is mature to be used in open source/lab/commercial products/use cases
- Project will still have right to use XGVela resources
Once a project has passed the Maturity Review, the project is in Mature State and may span over multiple releases.
To apply entering Mature State, the following contents are required
- History release: (how many release attend and major deliveries in each release)
- Architecture get along with XGVela architecture:
- Project is active and contributes to XGVela: The project demonstrates a stable or increasing number of contributions across recent releases. Contributions are commits which got merged to a repository of an XGVela project or a related upstream project. Commits can for example be patches to update the requirements document of a project, code addition to an XGVela or upstream project repository, new test cases and so forth.
- Project usage: The project can be successfully deployed, configured, and used by end users. Or it can be successfully integrated by commercial products.
2.4.2.3. Termination Review
The goal of the Termination Review is to ensure that:
- Artifacts for Mature State are complete and accepted
- Mature project artifacts are acceptable
- Project Team has the confidence that its artifacts can be used outside the XGVela community
- Metrics for Termination review are available
2.5. Release Process
Initially the TSC will make all decisions about Releases of the project. This may be amended by vote to include Project Committers as the project grows. However, to be able to measurable, the project must demonstrate a history of following the Release Process. The purpose of the Release Process is to assure 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 ‘Release Process’ should have a Release Plan published at the beginning of its release cycle by its Committers, after review by the TSC, 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 project in coordinating amount themselves and the general world in gaining visibility.
Release Plan and Release Review should contain roughly the following sections:
...