Page tree
Skip to end of metadata
Go to start of metadata

TSC Charter

Technical Steering Committee Charter

Version 6, Approved 6/8/16

Open-O TSC Charter

Section 1. Guiding Principle

The Open Orchestrator Project (OPEN-O) will operate transparently, openly, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders.

Section 2. Evolution of OPEN-O Governance

Most large, complex open source communities have both a business and a technical governance model. OPEN-O's technical leadership contains both a Technical Steering Committee (TSC) and Project Leads for major components. OPEN-O'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 OPEN-O. The TSC will span the entire Open Orchestrator project. The charter amendment process is for the TSC to propose changes using simple majority of the full TSC, the proposed changes being subject to review and approval by the Board. The TSC may additionally make amendments to the TSC charter at any time.

Section 3. GB’s Role in Setting OPEN-O Strategic Direction

The GB will set overall Project scope in consultation with the TSC and End-User Technical Advisory Board (EU-TAB). The scope will describe OPEN-O’s technical vision and direction and project release guidelines in the form of expected cadence and intent. 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.

Typically, the TSC will be independent on technical issues, including individual project scope and direction as long as they remain within the scope, vision and direction set by the Board.

Section 4. Establishment of the TSC

The TSC membership is defined in the Open Orchestrator Project Charter. During the startup period, intended to last for approximately two releases, it consists of Premier member designates (one per company). Following the startup phase, the TSC intends to create community representative votes on the TSC in order to include more community members from the OPEN-O projects. The transition from the startup phase to the long term TSC structure as well as a proposal for the number of seats on the TSC following the startup phase will be proposed by the TSC and approved by the GB. Such positions would be open for individual nominations and active maintainers and committers would elect the representative to serve a term of one year.

After the TSC transitions out of the startup phase, no single company, including its affiliated companies as defined in the Bylaws, and no single project may have more than three votes on the TSC. If a single company and its affiliated companies merits more than three TSC votes, one of the representatives must stand down.

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 OPEN-O 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.

The TSC will elect from amongst voting TSC members a Vice Chair of Architecture who will lead the Architecture committee. The Vice Chair of Architecture will also represent the TSC when the TSC Chair is not available. The TSC shall hold elections to select a Vice Chair of Architecture annually; there are no limits on the number of terms a Vice Chair may serve.

Section 5. Responsibilities of the TSC

Subject to such policies as may be set by the GB, the TSC is responsible for developing an architecture, setting project release dates, release quality standards, technical best practices (including the establishment and maintenance of a Development Process), monitoring technical progress, mediating technical conflicts between Committers and Project Leads, and organizing inter-project collaboration. The TSC will define OPEN-O’s release vehicles and serve as OPEN-O’s primary technical liaison body with other consortiums and groups.

Section 6. OPEN-O Operations

The TSC will establish and maintain a development process for OPEN-O and present it to the GB for approval.
There will be multiple projects under OPEN-O. Each project must be within such policies as may be set by the GB, have a well-defined scope and must work within that scope. The development process will provide for projects to follow the life-cycle process as described in the Project Lifecycle document. The development process will include a process for the TSC to oversee and approve changes in the lifecycle of a project (including a release) which will include consideration of the following criteria:

  • Cleanliness of code base.
  • Ample and diverse Contributors and Maintainers to assure vitality of the project.
  • Stability (e.g. presence of test suites and use of an appropriate source-code control system), Security, Scalability and Performance.
  • Predictability of releases.
  • Alignment with OPEN-O’s goals and priorities.
  • fThe TSC will work with LF, OPEN-O member companies, and/or other third parties to establish a development and testing environment to support the OPEN-O technical community.

Section 7. Elections and Voting

Leadership roles in OPEN-O, project leadership, and TSC community representative roles, will be held by peer elected representatives of the community. The development process for OPEN-O will include provisions for a voting process to be implemented for decision-making in accordance with the OPEN-O Charter.

For internal project decisions where no consensus can be reached, a majority vote among all Committers of the project via “+1/0/- 1” voting should be used. As described in the OPEN-O Charter, simple majority voting should be used for decisions within the TSC at which a quorum is present, unless otherwise required.
The development process will include such processes as may be specified by the GB from time to time relating to the intake and license compliance review of contributions.

Section 8. Project Roles

Each project has one or more Contributors, who provide project contributions such as code and documentation, and one or more Maintainers, who may also contribute and additionally control technical direction and the project repository. A Project Lead that sets overall direction for the project and reports to the TSC will head up each project.

Maintainer Roles

An OPEN-O Maintainer has two roles: Committers and Project Leads

Committers: For each project there is a set of people with rights to commit code or artifacts to the source code management system: the Committers.
The Committers will be the decision makers on design, code, packaging, and patches for their project. They must responsibly participate in the consensus decisions of the project.
Committer rights are earned via code contribution and community trust. Committers select and vote for new Committers, subject to TSC approval. The TSC has the authority to remove a committer. A standard meritocracy model with new Committers will be approved and implemented by the TSC which will include provision for fully open code submission, review, acceptance, build, test, delivery, and support model.
Committer rights are per project; being a Committer on one project does not necessarily give an individual committer rights on any other project.
Initial Committers and a nominated Project Lead will be specified at project creation. Additional Committers will be admitted by a vote of existing Committers with appropriate process to handle dissent. Committers are not necessarily from Member companies. Committers are best available individuals, but usually full-time for any components in active development.
The Committers will use the process established in the OPEN-O Project Lifecycle document and development process maintained by the TSC to manage releases and accept/force modifications/reject code submissions and to add/delete Committers (and other development details).

In order to preserve meritocracy in selection of Committers while ensuring diversity of Committers, each initial project will commit to taking on at least three Committers not from the company of origin within the first three months after OPEN-O is publicly launched based upon evaluation of participation of Contributors during that time

A Committer who is disruptive, or has been inactive for an extended period (e.g., six or more months) may have his or her Committer status revoked by the TSC. Project Leads must request the TSC for such an action to be taken.
In the event that a project has no active committers (e.g., due to job transfers, 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 other project Committers to maintain his or her status. This provision allows a project to continue development following an unexpected change in personnel.

Project Leads: The Project Lead is a Committer selected by vote from the Committers in the project. If there is initially only one member of the project, then that member is automatically the Project Lead. It is possible, and in some cases desirable, for one person to take on roles of Project Lead, Committer, and Contributor.

Contributor Role

Contributors: Most Contributors work with their Committer and their component’s sub-community. They contribute code or other artifacts, but do not have the right to commit to the code base. A Contributor may be promoted to a Committer by the projects’ Committers. Contributors should rarely be encumbered by the TSC and never by the GB.
The TSC shall, in conjunction with the OPEN-O community, refine and provide clarification of the project roles and responsibilities.

Section 9. 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).


Each subcommittee shall determine its own membership eligibility, in consultation with the TSC. It is expected that subcommittee membership shall be open to any OPEN-O 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 should be open to the OPEN-O membership. In particular, a Premier member has the right to appoint its TSC representative or a designate to such a subcommittee. Also, all TSC members are eligible to join a subcommittee.
Each subcommittee may elect a Chair who is responsible for leading meetings and representing the subcommittee to the TSC.

Advisory role

Subcommittees are advisory in nature, and not authoritative. They provide guidance to projects and to the TSC.
Subcommittees operate on a rough consensus basis. If the subcommittee is unable to reach consensus on a particular topic, 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.

Architecture Committee

The TSC shall establish an Architecture Committee. It shall be led by the Vice Chair of Architecture. The Architecture Committee is responsible for developing a long-term OPEN-O architecture. It may also consider information/data modeling approaches, and shall represent OPEN-O at external architecture and/or information/data modeling meetings. The Architecture Committee shall consult with Projects to help drive alignment between components and with the long-term architecture.