...
Guiding Principles
The ONAP Project a Series of LF Projects, LLC (“ONAP”) will operate transparently, openly, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders.
Structure of the Technical Community
The Technical Community consists of multiple projects and a Technical Steering Committee that spans across all projects.
Per Project
Project Roles
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.
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.
Committer rights are per project; being a Committer on one project does not give an individual committer rights on any other project.
The Committers will be the decision makers on all matters for a project including design, code, patches, and releases for a project.
Committers are the best available individuals, but usually work full-time on components in active development.
In order to preserve meritocracy in selection of Committers while ensuring diversity of Committers, each initial project are encouraged to take on at least three Committers from different companies (subject to meritocracy).
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.
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.
Project Technical Leader Voters
Only Committers for a project are eligible to vote for a project’s Project Technical Lead.
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
...
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 Committers of each of the subprojects. Each subproject will have its own set of committers 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.
...
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.
Core
Project provides value to and receives interest from a broad audience.
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.
...
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.
Longevity of the project
Project follows (or doesn't) the ONAP release cadence
Requirements have resulted in corresponding implementations
Comprehensiveness and maturity of the artifacts (code, test cases, documentation) the project produces including contributions/code to partner/upstream projects where applicable
Mature testing/integration success for defined environments (ONAP and/or partner/upstream projects, which is applicable or both)
Project artifacts: it is expected that all projects project’s artifacts are available and accessible to all contributors of the ONAP community. Links toward projects artifacts must be provided
Community Size and diversity of the active community (number and diversity of people contributing)
For each and every review the following steps are required:
The project review is posted two weeks in advanced advance in the Release Wiki. This allows all contributors to provide feedback prior to the review meeting. (include link when available)
The project review is emailed to onap-tsc@lists.onap.org mailing list
Disposition by TSC: Confirm that the project state is complete and the listed requirements are met.
Simple majority approval by voting TSC members
Reviews for multiple projects can occur at the same time.
During Release Kick-Off, the project team may request that the TSC conduct a review to move up the ladder.
Project Reviews
Incubation Review
The goal of the Incubation Review is to officially launch the 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.
Proposal template is available on the ONAP wiki .
The following artifacts are expected:
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 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)
Maturity Review
The goal of the Maturity Review is to ensure:
Artifacts for Incubation State are complete and accepted
Plan for Maturity State are accepted
Once a project has passed the Maturity Review, the project is in Mature State and may span over multiple releases.
Review metrics for Maturity review:
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).
Core Review
The goal of the Core Review is to ensure:
Artifacts for Maturity State are complete and accepted
Plan for Core State are accepted. For the Core Review it is expected to deliver a comprehensive integration plan
Once a project has passed the Core Review, the project is in Core State and may span over multiple releases.
Review metrics for Core review include the metrics for maturity review plus the following:
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).
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.
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.
Stability, Security, Scalability and Performance levels have reached a high bar.
...
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 amount among themselves and the general world in gaining visibility.
These should contain roughly the following sections:
Release Plan
Introduction
Release Deliverables
Release Milestones
Expected Dependencies on Other Projects
Compatibility with Previous Release
Themes and Priorities
Other
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 planed planned schedule and actual schedule
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 planed planned schedule and actual schedule
Amendments to the Technical Community Document
The TSC may make amendments to this Technical Community Document at any time. The document amendment process is for a TSC voting member to propose changes that will be decided by a simple majority of the full TSC. The proposed changes are subject to review and approval by the Series Manager of ONAP.
Technical Steering Committee
TSC Roles
TSC Members
TSC Membership Definitions
Active Community Members:
Anyone from the ONAP community with twenty (20) or more measurable contributions during the previous 12-month period, inclusive of code merged, code reviews performed, wiki page edits, (creation, modification, comments or attachments) or JIRA activities
Operator: Any of the original 9 Platinum Service Providers participating in ONAP at the beginning of 2018. (Specifically: AT&T, Bell, CMCC, China Telecom, Orange, Reliance Jio, Turk Telecom, Verizon and Vodafone)
(added July 12, 2018)TSC Size, Structure and Member Requirements
The TSC shall consist of eighteen (18) seats
Nine (9) seats on the TSC are to be reserved for Operators
Only one (1) person from any company, or group of related companies (as defined in section 4.4.4.1) may be a member at any given time.
Excluding the reserved seats provision of section 4.1.1.2, TSC membership is not limited to LFN member companies
TSC members shall be Active Community Members, notwithstanding the exception granted in section 4.2.3.2
(added July 12, 2018)TSC Chair
The TSC will elect from amongst voting TSC members a chairperson for a term of one year according to the ONAP Technical 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.
Chair Responsibilities
The primary responsibility of the TSC Chair is to represent the technical community in communications with the LF Networking Fund of The Linux Foundation and to be responsible for:
Leading TSC meetings;
This responsibility may be delegated to the 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 4.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.
Vice Chair 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.Coordinators
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.
A coordinator is an internal role, so while a coordinator may coordinate among various external liaisons in some instances, being a coordinator does not imply being the liaison to any particular external organization or group of organizations.
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.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.
Elections are held annually. There are no limits to the number of terms an individual can serve.
The coordinator will regularly report status and issues to the TSC via the ONAP-TSC email list.Coordinator and coordination area lifecycle
There is a lifecycle for the coordinator responsibility (coordination area) and the coordinator appointment.
Coordination Area Creation
A coordination area is created by sending a request to the TSC via the ONAP-TSC email list. The email shall have:
- Email Subject: Creation Request for coordination area: <coordination area name>
- Coordination Area responsibility description: <Description of the coordination area responsibilities>
- Reporting Cadence: <description of when reporting is expected to be delivered to the TSC>
- Area Coordinator: <Name of the area coordinator> (Can be blank)
The decision to create the coordination area is created by a TSC decision (per the TSC voting rules). A decision can be made with modification, with the modifications captured in the TSC minutes. Once a coordination area is created, it will be documented in the ONAP Wiki.
For the Area coordinator, see section: 4.2.2.2.Coordination Area Update
- A coordination area can be updated by sending a request to the TSC via the ONAP-TSC email list. The email shall have the following: Email subject: Update Request for coordination area: <coordination area name>
- Proposed Update: <Clearly described update of the coordination area. This could be the Area Responsibility Description; Reporting Cadence; Area Coordinator>.
The decision to update the coordination area is created by a TSC decision (according to the TSC voting rules). An update decision can be made with modification, with the modifications captured in the TSC minutes. Once a coordination area is updated, the updates will be documented in the ONAP Wiki.Coordination Area Termination.
A coordination area can be terminated by sending an email to the TSC via the ONAP-TSC email list. The email shall have the following.
- Email Subject: Close Request for coordination area: <coordination area name>
- Motivation: <Motivation for closing the coordination area>.
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.TSC Operations
TSC Decision Making Process
Decisions of the TSC should be made by majority vote of TSC Members.
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.
TSC Chair/Vice Chair Candidates
Candidates for TSC Chair or Vice Chair must be TSC Members as defined in Section 4.1.1.
Candidates must self nominate.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.
TSC Chair/Vice Chair/Coordinator Voters
Only TSC Members are eligible to vote for TSC Chair/Vice Chair/Coordinator.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\TSC Member Elections
Candidate and Voter Eligibility
Any Active Community Member (regardless of LFN membership), is eligible to run for a TSC seat, except as provided for in section 4.2.3.2
Any Active Community Member (regardless of LFN membership), is eligible to vote in a TSC election
Eligibility is effective as of the date and time the nomination process starts
(added July 12, 2018)TSC Member Candidates
There are no limitations on the number of candidates that can run for a TSC seat, nor is there a limit to the number of candidates from any company, or group of related companies that can run in a TSC election
Candidates must self nominate
At least one person from each Operator must run for that Operator's reserved seat
A provision is granted for an Operator to appoint a person to run for their seat, only in the event that the Operator does not have any eligible Active Community Members at the time of nomination process.TSC Member Election Mechanics
The election of a TSC Member shall consist of a single stack ranked vote of all candidates via CIVS ( Condorcet: http://en.wikipedia.org/wiki/Condorcet_method);
The top ranked candidate from each Operator will be selected, for a total of nine members, one member from each Operator
The top ranked non-Operator candidates (whether affiliated with a company or an individual contributor), will be selected for the remaining nine seats, with no more than one member per company or group of related companies being selected.TSC Member Standing Down
If a TSC member is no longer able to perform the TSC duties, the TSC member may inform via an email to the TSC email list.
If a TSC member moves companies, that member must notify the TSC via an email to the TSC email list. That TSC member may remain a member unless: 1) the moves places the member in conflict with the TSC composition rules, or 2) the TSC member (at his/her determination) will no longer be able to perform their TSC duties.Replacement of a TSC member standing down
In the event of a TSC member standing down:
If the TSC position was from an defined operator, the operator may appoint a member that fulfills the criteria of being an active member; if that is not feasible then the operator may appoint any member. If neither is done within 60 days, then the seat is considered vacant until the next election, and the seat does not count toward quorum requirements.
If the TSC position is from one of the elected positions (i.e. non reserved seat), an election for that single position is held within 60 days of notification. The conditions of the election are the same as for any TSC election.
If the said position was of that of a TSC chair or vice-chair, then the TSC chair or vice chair position will undergo a re-election after the successful appointment or election of the new TSC member.
When the next General TSC election is held, any seat filled via 4.2.3.4 will also be included in the general TSC election.
(added October 18, 2018)Responsibilities of the TSC.
Subject to the Technical Charter, the TSC is responsible for:
Defining ONAP’s release vehicles (such as a Coordinated Release) that align with the Project’s,mission,
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 PTLs,
organizing inter-project collaboration,
coordinating technical community engagement with the end-user community(creation, modification, comment or closure).
An exception may be granted at the full discretion of the TSC if an individual fails to meet the Active Community Member criteria only under the condition that the TSC has delegated some level of responsibility for participating in an external open source community or standards body to that individual. For an exception to be considered the individual must request it themselves by sending an email to the onap-tsc list, which demonstrates all of the following criteria have been met:
The individual has made at least some measurable contributions directly to the ONAP community in the previous 12-month period
The total number of combined measurable contributions (ONAP + external) would meet the Active Community Member threshold
The external contributions have been made specifically on behalf of the ONAP community and not in the exclusive service of the individual's employer
A pointer to the relevant records from the external source to be included in the count has been provided
Related Company
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.
TSC Members
TSC Size and Structure
TSC members shall be Active Community Members in order to qualify for, or to retain any seat on the TSC.
All seats on the TSC are open to any qualified candidate irrespective of their employment status, the company they may work for, the type of business or industry vertical they may be associated with or of their LF or LFN membership status.
There shall be up to a maximum of 25 seats permitted on the TSC. There is no requirement for all 25 seats to be filled at any given time.
Any seats left vacant following a regular annual election shall remain vacant until the next annual election.
One Person Per Company Rule
Although TSC seats are issued to individuals and not to companies, only one (1) person from any company, or group of Related Companies may be a member of the TSC at any given time. Exceptions to this rule are:
A sitting TSC member impacted by merger & acquisition activity involving their company may retain their TSC seat until the next annual TSC election cycle.
An incumbent TSC member that wins a Special Election as defined in this document, following a job change.
Proxy Representation
TSC members may assign a proxy representative that may both attend meetings and/or vote (either live or electronically) on their behalf to accommodate business conflicts, travel, holiday periods or personal time off
All proxies must be reasonably time-bound.
The TSC must be pre-notified of the proxy and the coverage duration in advance via an email to the onap-tsc mailing list.
There are no provisions for a default, standing or de facto proxy assignment for any TSC member.
"Self-announced" proxies are not permitted and will not be recognized.
TSC Membership Requirements and Expectations
Meeting Attendance
TSC members are expected to regularly attend TSC meetings
If any TSC member, without being represented by a proxy misses any two consecutive regular TSC meetings, such member shall not be counted for quorum or voting purposes until that member next attends.
If any TSC member, without being represented by a proxy, misses any four consecutive regular TSC meetings, that member shall be removed from the TSC automatically unless the TSC approves an exception.
Dedicated work time for TSC related activities
TSC members are expected to dedicate at least 3-4 hours weekly on average to perform the type of work outlined in this document. If a potential member is not able to commit to such a time investment, it is strongly recommended they do not run as a candidate for any TSC seat.
Direct Community Leadership
TSC members are expected to take on some manner of Community Leadership role beyond the TSC seat itself.
The Community Leadership role must serve the needs and/or benefits of the ONAP community as a whole and not serve the exclusive needs and/or of the member's company.
Examples of Community Leadership roles include but are not limited to:
Project PTL
Subcommittee Officer
A TSC work group or task force leader
Community Coordinator (TAC, MAC, SPC, SDO or other OSS)
LFN or other OSS Whitepaper or blueprint editor/contributor
LFN (or other OSS) Event organizer
Active Participation in basic TSC operations
TSC members are expected to actively take part in fulfilling the TSC responsibilities as defined in the ONAP charter and this document. That may include (but is not limited to):
Bringing forth proposals for improvements in the software or software development process.
Proposing solutions to issues raised by the community and brought to the TSC for a decision.
Pulling in experts from their company or organization to help address issues brought before the TSC.
ONAP Advocacy
TSC members are expected to advocate for the adoption and use of ONAP by their company/organization or other OSS projects and use cases. Advocacy may take the form of public posts (blogs, articles, white papers, blueprints, etc.), or via direct communication with the relevant parties.
Responsibilities of the TSC.
Subject to the Technical Charter, the TSC is responsible for:
Defining ONAP’s release vehicles (such as a Coordinated Release) that align with the Project’s,mission,
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 PTLs,
Organizing inter-project collaboration,
Coordinating technical community engagement with the end-user community.
TSC Chair
The TSC will elect from amongst voting TSC members a chairperson for a term of one year according to the ONAP Technical 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.
Chair Responsibilities
The primary responsibility of the TSC Chair is to represent the technical community in communications with the LF Networking Fund of The Linux Foundation and to be responsible for:
Leading TSC meetings;
This responsibility may be delegated to the 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 as defined in this document.
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.
Vice Chair Responsibilities
The Vice Chair will support the TSC Chair.
The Vice Chair will represent the TSC when the TSC Chair is not available unless another delegation has been made explicitly.
Coordinators
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.
A coordinator is an internal role, so while a coordinator may coordinate among various external liaisons in some instances, being a coordinator does not imply being the liaison to any particular external organization or group of organizations.
Coordinators support the TSC Chair in the execution of TSC responsibilities 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.
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.
Elections are held annually. There are no limits to the number of terms an individual can serve.
The coordinator will regularly report status and issues to the TSC via the ONAP-TSC email list.
Coordinator and coordination area lifecycle
There is a lifecycle for the coordinator responsibility (coordination area) and the coordinator appointment.
Coordination Area Creation
A coordination area is created by sending a request to the TSC via the ONAP-TSC email list. The email shall have:
Email Subject: Creation Request for coordination area: <coordination area name>
Coordination Area responsibility description: <Description of the coordination area responsibilities>
Reporting Cadence: <description of when reporting is expected to be delivered to the TSC>
Area Coordinator: <Name of the area coordinator> (Can be blank)
The decision to create the coordination area is created by a TSC decision (per the TSC voting rules). A decision can be made with modification, with the modifications captured in the TSC minutes. Once a coordination area is created, it will be documented in the ONAP Wiki.
Coordination Area Update
A coordination area can be updated by sending a request to the TSC via the ONAP-TSC email list. The email shall have the following: Email subject: Update Request for coordination area: <coordination area name>
Proposed Update: <Clearly described update of the coordination area. This could be the Area Responsibility Description; Reporting Cadence; Area Coordinator>.
The decision to update the coordination area is created by a TSC decision (according to the TSC voting rules). An update decision can be made with modification, with the modifications captured in the TSC minutes. Once a coordination area is updated, the updates will be documented in the ONAP Wiki.
Coordination Area Termination.
A coordination area can be terminated by sending an email to the TSC via the ONAP-TSC email list. The email shall have the following.
Email Subject: Close Request for coordination area: <coordination area name>
Motivation: <Motivation for closing the coordination area>.
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.
TSC Operations
TSC Decision Making Process
Decisions of the TSC should be made by majority vote of TSC Members.
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 within the community.
TSC Chair/Vice Chair Candidates
Candidates for TSC Chair or Vice Chair must be TSC Members as defined in this document.
Candidates must self nominate.
Coordinator Candidates
Any community member, regardless of TSC membership or Active Community Member status, is eligible to serve as a Coordinator. Nominees should have subject matter experience in the relevant coordination area.
Candidates must self nominate.
TSC Chair/Vice Chair/Coordinator Voters
Only TSC Members are eligible to vote for TSC Chair, Vice Chair and Coordinator positions.
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
Replacement of a TSC officer
In the event of aTSC Chair/Vice Chair standing down, the position will undergo a re-election with the candidate pool limited to the current TSC members
TSC Member Elections
The regular elections of the TSC shall occur annually in September
Candidate and Voter Eligibility
Any Active Community Member is eligible to run for a TSC seat
Any Active Community Member is eligible to vote in a TSC election
Eligibility as an Active Community Member to either run for a TSC seat or vote is determined effective as of the date and time the nomination process starts
Currently serving in a Community Leadership capacity is not a prerequisite for a candidate’s eligibility in any TSC election
TSC Member Candidates
There are no limitations on the number of candidates that can run for a TSC seat, nor is there a limit to the number of candidates from any company, or group of Related Companies that can run in a TSC election
Candidates must self nominate
TSC Member Election Mechanics
The election of a TSC Member shall consist of a single stack ranked vote of all candidates such as Condorcet: http://en.wikipedia.org/wiki/Condorcet_method);
The top ranked candidates in the election shall be elected to serve on the TSC up to the maximum number of seats allowed
If multiple candidates from a company or a group of Related Companies are running in the election only the top ranked candidate in the election shall be elected.
Special Elections
Special Elections will not be held during the months of July and August. The next opportunity to address any seat or membership changes on the TSC will be at the next regular election and all regular election provisions shall apply.
In the event of the resignation or removal of a TSC member, the TSC may either call for a Special Election, or choose to leave the seat open until the next regular election cycle, by a simple majority vote of the TSC
In the event of a TSC Member’s change of employment creates a conflict with the One Person Per Company Rule a Special Election is to be held.
TSC Member Job Status Changes
If a TSC member is no longer able to perform their TSC duties, the TSC member may step down by informing the community via an email to the TSC email list.
Any TSC member that changes companies or employment status must notify the TSC via an email to the ONAP TSC list.
If there is no conflict with the One Person Per Company Rule, a TSC Member will retain their seat provided any new responsibilities do not impact their ability to meet the obligations outlined in this document.
If there is a conflict with the One Person Per Company Rule, the incumbent TSC member may run in the Special Election to retain their seat if they choose to do so. If elected they may retain their seat until the next regular TSC election cycle.
There are no provisions permitting a company or group of Related Companies to appoint a replacement into a seat vacated by one of their employees.
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).
Membership
Subcommittee Membership Eligibility
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 or group of Related Companies. 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 All elected TSC members are eligible to join a subcommittee
Subcommittee Chair / Vice Chair
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)
Subcommittee Chair / Vice Chair Elections
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)election.
Subcommittee Voter Eligibility
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)to ONAP member companies. However only 1 Subcommittee member from each company, or group of related companies may vote in the election.
Subcommittee Election Confirmation
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)
Advisory roleRole of the Subcommittee
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.
...