Superseded by Jan 1, 2018 Charter
| Table of Contents | ||
|---|---|---|
|
1 Guiding Principles
1.1
The Open Network Automation Platform (ONAP) will operate transparently, openly, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders.
1.2
ONAP will consist of multiple, independent, projects.
...
Nothing in this charter shall be interpreted in such a way as to violate these principles.
2 Structure of the Technical Community
The Technical Community consists of multiple projects and a Technical Steering Committee that spans across all projects.
3 Per Project
3.1 Project Roles
3.1.1 Contributor
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.
3.1.2 Committer
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.
...
In order to preserve meritocracy in selection of Committers while ensuring diversity of Committers, each initial project are encouraged to taking on at least three Committers from different companies (subject to meritocracy).
3.1.3 Project Technical Leader:
A project is required to elect a Project Technical Leader (PTL). The PTL acts as the de facto spokesperson for the project.
3.1.3.1 Project Technical Leader Candidates
Candidates for the project’s Project Technical Leader will be derived from the Committers of the Project.
Candidates must self nominate.
3.1.3.2 Project Technical Leader Voters
Only Committers for a project are eligible to vote for a project’s Project Technical Lead.
3.1.3.3 Project Technical Leader Election Mechanics
An election for Project Technical Leader occurs when any of the following are true:
The project is initially created
The Project Technical Leader resigns his or her post
The majority of committers on a project vote to call a new election
One year has passed since the last Project Technical Leader election for that project
3.1.4 Maintainer
Maintainer is defined as being a term precisely equivalent to committer. Committer should be used in preference. Maintainer is mentioned here because it was mentioned in the ONAP Charter.
3.2 Project Operations
3.2.1 Project Decisions Making Process
Technical and release decisions for a project should be made by consensus of that 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.
3.2.2 Committer Lifecycle
3.2.2.1 Adding Committers
- Initial Committers for a project will be specified at project creation
- Committer rights for a project are earned via contribution and community trust. Committers for a project select and vote for new Committers for that project, subject to TSC approval.
- New Committers for a project should have a demonstrable established history of meritocratic contributions.3.
3.2.2.2 Adding Committers 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 ONAP-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.
3.2.2.3 Removing Committers
A Committer may voluntarily resign from a project by making a public request to the PTL to resign (via the project and ONAP-TSC email lists).
...
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.
3.2.3 Umbrella Projects
The TSC may create umbrella projects (“Umbrella Projects”) that in turn support multiple sub-projects. Umbrella Projects will be led by an Umbrella Committee made up of the PTL and one or more committers, who are the committers of each of the subprojects. Each subproject will have its own set of committers with responsibility only for the subproject repository.
With the approval of the TSC, Umbrella Projects may establish and modify additional technical roles for sub-project participants.
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 use case(s).
...
This document covers the ONAP project lifecycle. The Release Lifecycle is documented in a separate document (include link when ready).
3.3.2 Project Lifecycle Overview
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.
...
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.
3.3.3 Project Lifecycle States and Reviews
ONAP project lifecycle defines five 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.
...
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 two ways:
...
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
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.
...
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.
...
Name of the project is appropriate (no trademark issues etc.); Proposed repository name is all lower-case without any special characters
Project contact name, company and email are defined and documented
Description of the project goal and its purpose are defined
Scope and project plan are well defined
Resources committed and available
Contributors identified
Initial list of Committers identified (elected/proposed by initial contributors)
Meets ONAP TSC Policies
Proposal has been socialized with potentially interested or affected projects and/or parties
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
Tools have been identified and discussed with relevant partners (Linux Foundation, IT). Once the project pass the review, the tools chain must 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:
...
Successful participation in releases: The project demonstrates stable output (code base, documents) within its history of releases in accordance with the release policy.
Architecture has been reviewed by the Architecture Committee
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.
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:
...
Artifacts for Core state are complete and accepted
Core project artifacts are acceptable and meet the acceptance criteria
Project Team has the confidence that its artifacts can be used outside the ONAP community
Metrics for Termination review are available
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 insure 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.
...
These should contain roughly the following sections:
3.3.7.1 Release Plan
Introduction
Release Deliverables
Release Milestones
Expected Dependencies on Other Projects
Compatibility with Previous Release
Themes and Priorities
Other
3.3.7.2 Release Review
Features delivered
Non-Code Aspects (user docs, examples, tutorials, articles)
Architectural Issues (if any)
Security Issues (if any)
Quality Assurance (test coverage, etc)
End-of-life (API/Features EOLed in Release)
Summary of Outstanding Bugs
Summary of Standards Compliance
Delta between planned schedule and actual schedule
4 ONAP Governance
4.1 ONAP Governance Introduction
Most large, complex open source communities have both a business and a technical governance model. ONAP's technical leadership contains both a Technical Steering Committee (TSC) and Project Leads for major components. ONAP's business leadership is instantiated in a Governing Board (the “GB”).
This Technical Steering Committee Charter reflects a carefully constructed balanced role for the TSC and the Board in the governance of ONAP. The TSC will span the entire ONAP project.
4.2 Governing board’s role in setting the ONAP strategic direction
The GB will set overall Project scope in consultation with the TSC. The scope will describe ONAP’s technical vision and direction and project release guidelines in the form of expected cadence and intent expressed by use cases, user stories, and priorities. The GB will use the TSC as a delegate body for governing all aspects of a release, including release planning, release criteria, technical implementation, infrastructure, development environment, individual project scope and direction.
4.3 Technical Steering Committee’s role in setting the direction for the technical community
The TSC is the delegated body for governing all aspects of a release, including release planning, release criteria, technical implementation, infrastructure, development environment, individual project scope and direction.
...
Typically, the TSC will be independent on technical issues, including individual project scope and direction as long as they remain aligned with the scope, vision and direction set by the Board.
4.4 TSC charter evolution.
The TSC may make amendments to the TSC charter at any time. The charter amendment process is for a TSC voting member to propose changes that will be decided by simple majority of the full TSC. The proposed changes are subject to review and approval by the Board.
5 Technical Steering Committee
5.1 TSC Roles
5.1.1 TSC Members
TSC Membership shall consist of Platinum Designates: One member designated by each Platinum Member, until such time, anticipated to be 12 months from launch, that TSC Membership can be transitioned to community representation via a mechanism defined by the TSC and approved by the board.
5.1.2 TSC Chair
The TSC will elect from amongst voting TSC members a chairperson who will represent the TSC to the GB for a term of one year according to the ONAP Charter. The TSC shall hold elections to select a TSC Chair annually; there are no limits on the number of terms a TSC Chair may serve.
5.1.2.1 Responsibilities
The primary responsibility of the TSC Chair is to represent the technical community on the Governing Board. The TSC Chair is also responsible for:
Leading TSC meetings;
This responsibility may be delegated to another TSC member (in such case, this is to be informed via the TSC email list)
Representing the technical community to external organizations.
These responsibilities may be delegated to another member of the technical community.
Lead the TSC in the execution of the TSCs responsibilities (section 5.3).
5.1.3 Vice Chair
The TSC will elect from amongst voting TSC members a Vice Chair. The TSC shall hold elections to select a Vice Chair annually; there are no limits on the number of terms a Vice Chair may serve.
5.1.3.1 Responsibilities
The Vice Chair will support the TSC Chair.
The Vice Chair will represent the TSC when the TSC Chair is not available unless other delegation has been made explicitly.
5.1.4 Coordinators
5.1.4.1 Coordinator Description
The TSC has multiple coordinator roles. Each coordinator role comes with its own set of responsibilities to discharge in serving the community via coordinating among various parties.
...
Coordinators support the TSC Chair in the execution of TSC responsibilities (Section 5.3) and the delivery of ONAP releases. They are responsible for fostering collaboration among the many parties that need to work together to identify, characterize, and solve problems, they do not direct solutions.
5.1.4.2 Coordinator origin.
The Technical Steering committee may elect coordinators from the Technical Steering Committee or from community participants. The TSC will solicit nominations for the role. Nominees should have subject matter experience in the relevant coordination area. In the event that multiple candidates self-nominate, the TSC will hold an election.
...
The coordinator will regularly report status and issues to the TSC via the ONAP-TSC email list.
5.1.4.3 Coordinator and coordination area lifecycle
There is a lifecycle for the coordinator responsibility (coordination area) and the coordinator appointment.
...
The decision to close the coordination area is created by a TSC decision (according to the TSC voting rules). Once a coordination area is updated, the coordination area will be removed from the ONAP Wiki.
5.2 TSC Operations
5.2.1 TSC Decision Making Process
Decisions of the TSC should be made by majority vote of TSC Members.
5.2.2 TSC Chair/Vice Chair/Coordinator Elections
The TSC Chair/Vice Chair/Coordinators shall be elected separately. There is no prohibition against a person holding multiple roles.
5.2.2.1 TSC Chair/Vice Chair Candidates
Candidates for TSC Chair or Vice Chair must be TSC Members as defined in Section 5.1.1.
...
Candidates must self nominate.
5.2.2.2 Coordinator Candidates
Any community member (regardless of TSC membership) is eligible to serve as a coordinator. Nominees should have subject matter experience in the relevant coordination area.
...
Candidates must self nominate.
5.2.2.3 TSC Chair/Vice Chair/Coordinator Voters
Only TSC Members (Section 5.1.1) are eligible to vote for TSC Chair/Vice Chair/Coordinator.
5.2.2.4 TSC Chair/Vice Chair/Coordinator Election Mechanics
Election of a TSC Chair/Vice Chair/Coordinator shall use a multiple-candidate method, e.g.:
...
Condorcet: http://en.wikipedia.org/wiki/Condorcet_method; or Single Transferable Vote: http://en.wikipedia.org/wiki/Single_transferable_vote
5.3 Responsibilities of the TSC.
Subject to such policies as may be set by the GB, the TSC is responsible for:
...
Defining ONAP’s release vehicles (such as a Coordinated Release) that align with the scope as directed by the GB,
Fostering cross-project collaboration,
Serving as ONAP’s primary technical liaison body with other consortiums and groups,
developing an architecture,
setting simultaneous release dates,
defining release quality standards,
defining technical best practices and community norms (including the establishment and maintenance of a Development Process),
monitoring technical progress,
mediating technical conflicts between Committers and Project Leads,
organizing inter-project collaboration,
coordinating technical community engagement with the end-user community.
5.4 TSC Subcommittees
The TSC, at its discretion, may establish subcommittees to assist the TSC with its responsibilities and provide expert guidance in technical subject areas (e.g., architecture or security).
5.4.1 Membership
5.4.1.1
Each subcommittee shall determine its own membership eligibility, in consultation with the TSC. It is expected that subcommittee membership shall be open to all ONAP Contributors; however, subcommittees may impose restrictions such as the number of participants from a single company. While the desire may be to keep its size and scope limited, each subcommittee shall be open to the ONAP membership. In particular, a Platinum member has the right to appoint its TSC representative or a designate to such a subcommittee. Also, all elected TSC members are eligible to join a subcommittee
5.4.1.2
Each subcommittee may elect a Chair and optionally a Vice-Chair who is responsible for leading meetings and representing the subcommittee to the TSC. (amended July, 27, 2017)
5.4.1.3
The Chair or Vice-Chair will be elected by members of the subcommittee as of the date the nomination process starts for the election. (added July, 27, 2017)
5.4.1.4
Voting for a Chair or Vice-Chair is not limited to ONAP member companies. However only 1 Subcommittee member from each company, or group of related companies may vote in the election.
...
For the purpose of this document, “Related Company” shall mean any entity (Company-A) which controls or is controlled by another entity (Company-B) or which, together, is under the common control of a third party (Company-C), in each case where such control results from ownership, either directly or indirectly, of more than fifty percent of the voting securities or membership interests of the entity in question; and “Related Companies” are entities that are each a Related Company as described above. (added August 14, 2017)
5.4.1.5
The elected Chair (and/or Vice-Chair) is submitted to the TSC for confirmation. The TSC decides to accept the outcome or requests a new voting. (added July, 27, 2017)
5.4.2 Advisory role
Subcommittees are advisory in nature, and not authoritative. They provide advice to projects and to the TSC.
...
Subcommittees operate on a rough consensus basis. If the subcommittee is unable to reach consensus on what advice to offer, the subcommittee Chair shall raise the issue with the TSC, where a formal vote can be taken, or advise the project that the subcommittee cannot reach consensus.
5.4.3 TSC subcommittee lifecycle.
5.4.3.1 Creation of a TSC subcommittee
The TSC decides the creation of a subcommittee in accordance with TSC decision procedure.
...
TSC subcommittee name.
TSC subcommittee purpose: <Description of subcommittee purpose>
TSC subcommittee expected deliverables:<List of expected deliverables>
TSC subcommittee starting participants: <List of expected starting participants>
Optionally TSC subcommittee definition of done: <Description of what is expected at the conclusion of the subcommittee. This may relate to the deliverables>
5.4.3.2 Update of a TSC subcommittee
The TSC can modify a TSC subcommittee via a TSC decision. To request such a modification, a request is made to the ONAP-TSC email list.
5.4.3.3 Conclusion of a TSC subcommittee
The TSC decides the termination of the TSC subcommittee in accordance with the TSC decision procedure. The submission of a request to terminate the TSC subcommittee should cover:
...
TSC subcommittee name
TSC subcommittee deliveries: <description of what has been achieved>
Motivation for termination of TSC subcommittee: <Reason for requesting the termination of the subcommittee>
5.4.4 Subcommittee vs. coordinator
As a guideline, a subcommittee is most appropriate when the task to be addressed involves a relatively stable group of people with a high level of intersection of common involvement. A coordinator is more appropriate when there is a more dynamic group of people and issues may change frequently. A coordinator is also more appropriate for smaller efforts or topics requiring infrequent meetings.
...