The Technical Community consists of multiple projects and a Technical Steering Committee that spans across all projects.
A Contributor is someone who contributes to a project. Contributions could take the form of code, code reviews, or other artifacts. Contributors work with a project’s Committer and the project’s sub-community. A Contributor may be promoted to a Committer by the project’s Committers after demonstrating a history of meritocratic contribution to that project.
For each project there is a set of Contributors approved for the right to commit code to the source code management system (the “Committers”) for that project.
2.1.2.1. Adding Committer
2.1.2.2. Removing Committer
A Committer may voluntarily resign from a project by making a public request to the PTL to resign (via https://lists.xgvela.org/g/main mail list).
A Committer for a project who is disruptive, or has been inactive on that project for an extended period (e.g., six or more months) may have his or her Committer status revoked by the project’s Project Technical Leader or by 2/3 super-majority vote of the project’s committers. The Project Technical Leader is responsible for informing the Technical Steering Committee (TSC) of any committers who are removed or resign via the https://lists.xgvela.org/g/main mail list.
Former committers removed for reasons other than being disruptive may be listed as ‘Emeritus Committers’. That title expresses gratitude for their service, but conveys none of the privileges of being a Committer.
2.1.2.3. Adding Committer to moribund projects
In the event that a project has no active committers (e.g., due to resignations, etc.), the TSC may appoint an interim Committer from a project’s active Contributors. This term shall last until the next release date, after which time the Committer must stand for election from amongst other Committers on the project to maintain his or her status. In this special case, approval requires a majority of committers who respond within two weeks. If no one responds by the deadline, then the committer status is approved. This provision allows a project to continue development following an unexpected change in personnel.
The method by which the TSC appoints an interim committee is first by request to the XGVela TSC email list indicating the request to appoint an interim Committer for a project. After the reception of such an email, the normal TSC decision process applies.
A project is required to elect a Project Technical Leader (“PTL”). The PTL acts as the de facto spokesperson for the project.
2.1.3.1. PTL Candidates
Candidates for the project’s Project Technical Leader will be derived from the Committers of the Project. Candidates must self nominate.
2.1.3.2. PTL Voters
Only Committers for a project are eligible to vote for a project’s Project Technical Lead.
2.1.3.3. Project Election Mechanics
An election for Project Technical Leader occurs when any of the following are true:
Technical and release decisions for a project should be made by consensus of 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.
The activities of the XGVela community are articulated around projects and releases. The scope of each project is aligned with the XGVela architecture and the scope of each release is defined with the objective to fulfill a particular use case(s).
A project is a long-term endeavor setup to deliver features across multiple releases, which have a shorter lifespan.
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.
An XGVela release can be composed of 1 to N projects. As such the number of contributing projects to a particular release may vary overtime.
A release is initiated to deliver a set of project deliverables.
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.
As PaaS is a group of independent functionalities which are used case by case, XGVela projects are usually not tightly-connected with each other. Usually XGVela projects can be separated into two types:
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