Resolution vote to Approve: https://lists.project-emco.io/g/emco-tsc-pvt/message/1
Draft initiated: March 1st 2022
Current status: Approved

Technical Steering Committee


    • The Technical Steering Committee (the “TSC”) will be responsible for all technical oversight of the open source Project. 

    • The TSC voting members will be comprised of select members from among the Project’s Committers. At the inception of the project, the TSC voting members are appointed by participating companies, with each company, including any Related Company (see definition of Related Company in Section 2.c below), appointing only one (1) representative,  as set forth within the TSC Representative Table, located on the EMCO designated Technical Steering Committee wiki page. The TSC may choose an alternative approach for determining the voting members of the TSC, and any such alternative approach will be documented on the designated EMCO Technical Steering Committee wiki page.  Any meetings of the Technical Steering Committee are intended to be open to the public, and can be conducted electronically, via teleconference, or in person. 

    • 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.

    • TSC projects generally will involve Contributors and Committers. The TSC may adopt or modify roles so long as the roles are documented in the CONTRIBUTING file. Unless otherwise documented:
      • Contributors include anyone in the technical community that contributes and/or reviews, code, documentation, or other technical artifacts to the Project;
      • Committers are Contributors who have earned the ability to approve source code, documentation or other technical artifacts in a project’s repository to be committed to the repository, as long as at least one other Contributor (or Committer) has also approved; and
      • A Contributor may become a Committer by a majority approval of the existing Committers. A Committer may be removed by a majority approval of the other existing Committers.
    • Participation in the Project through becoming a Contributor and Committer is open to anyone so long as they abide by the terms of the Project Charter.
    • The TSC may (1) establish workflow procedures for the submission, approval, and closure/archiving of projects, (2) set requirements for the promotion of Contributors to Committer status, as applicable, and (3) amend, adjust, refine and/or eliminate the roles of Contributors, and Committers, and create new roles, and publicly document any TSC roles, as it sees fit.
    • The TSC may elect a TSC Chair, who will preside over meetings of the TSC and will serve until their resignation or replacement by the TSC.  If in the future a directed fund of the Linux Foundation is established to support the Project, or the Project joins a directed fund of the Linux Foundation, the TSC Chair, or any other TSC member so designated by the TSC, will serve as the primary communication contact between the Project and the applicable directed fund.
    • Responsibilities: The TSC will be responsible for all aspects of oversight relating to the Project, which may include:
      1. coordinating the technical direction of the Project;
      2. approving project or system proposals (including, but not limited to, incubation, deprecation, and changes to a sub-project’s scope);
      3. organizing sub-projects and removing sub-projects;
      4. creating sub-committees or working groups to focus on cross-project technical issues and requirements;
      5. appointing representatives to work with other open source or open standards communities;
      6. establishing community norms, workflows, issuing releases, and security issue reporting policies;
      7. approving and implementing policies and processes for contributing (to be published in the CONTRIBUTING file) and coordinating with the series manager of the Project (as provided for in the Series Agreement, the “Series Manager”) to resolve matters or concerns that may arise as set forth in Section 7 of this Charter (#### reference missing within this document and Charter PDF is also missing from the wiki, apparently);
      8. discussions, seeking consensus, and where necessary, voting on technical matters relating to the code base that affect multiple projects; and
      9. coordinating any marketing, events, or communications regarding the Project.

TSC Voting

    • While the Project aims to operate as a consensus-based community, if any TSC decision requires a vote to move the Project forward, the voting members of the TSC will vote on a one vote per voting member basis.
    • Quorum for TSC meetings requires at least fifty percent of all voting members of the TSC to be present. The TSC may continue to meet if quorum is not met but will be prevented from making any decisions at the meeting.
    • Except as provided in Section 7.c. and 8.a, decisions by vote at a meeting require a majority vote of those in attendance, provided quorum is met. Decisions made by electronic vote without a meeting require a majority vote of all voting members of the TSC.
    • In the event a vote cannot be resolved by the TSC, any voting member of the TSC may refer the matter to the Series Manager for assistance in reaching a resolution.

Project Roles

  • An initial TSC has been established per above. TSC eligibility is defined per above and aligns with the Technical Charter. Contributor and Committer are defined per above. TSC Chair, TAC representative, and MAC liaison roles will be assigned through nomination, then TSC voting. Additional roles, including Project Technical Leads (PTLs) may be defined as project needs arise.
  • The current TSC Rep table is here. The TSC represents the top-level decision-making bode for the project.
  • Additional project roles, as needed, are filled by TSC voting (majority)
  • Removal from a Project Role- 
    • A person may voluntarily resign from a project role by making a public announcement to the TSC.
    • A person in a project role who is disruptive, or has been inactive on that project for an extended period (e.g., six or more months), or is not abiding by the project charter or code of conduct may have his or her role status revoked by the TSC.
  • Disputes are resolved TSC voting (majority)


Approved Amendment- Ecosystem Projects

  • Anything that is not specified in this section must be followed consistently with the rest of Governance, such as the approval process for new projects/repositories.
  • Ecosystem projects may adopt a different model of Contributor vs. Committer, and may choose the code approval/merging process that is more appropriate to their team.
  • The TSC does not recognize official PTLs for any of the Ecosystem projects.
  • Ecosystem projects do not have any expectation of aligning with EMCO's release cycle or reporting on progress.
  • Ecosystem projects are expected to related to EMCO in some capacity (examples include documentation, proofs of concept, extensions, deployment scenarios, third-party integration, etc.).
  • Code licensing will comply with Project Charter.
  • Acceptance Process & Criteria:


Project Roles


Current subgroups, projects, PTLs and Project's committers:


The Governance set forth here may evolve over time based on project needs, and shall be agreed upon by the TSC in place at that time.

  • No labels

5 Comments

  1. Re. "Should code licensing be mentioned in Governance", Linux Foundation does not seem to mandate a specific license. We should add a clause that all contributions should be open-source, consistent with Linux Foundation's principles and guidelines.

    Specifically, LF 1 says: "Open source software is defined by the OSI’s Open Source Definition.

    Also 2: "The SPDX License List (https://spdx.org/licenses/) has been curated by lawyers working in the open source ecosystem "

    1 https://www.linuxfoundation.org/tag/licensing/ 

    2 https://www.linuxfoundation.org/tools/a-guide-to-open-source-software-for-procurement-professionals/ 

  2. Add description to define Ecosystem project. And any criteria

  3. We should consider streamlining and clarifying the the approval process in the governance doc.

  4. A wiki page should be created describing what Ecosystem projects are and what is the recommended path to request a new one to be created (approved by TSC).

  5. As discussed on yestersays EMCO TSC meeting, since we didn't have quorum of TSC representatives, an email vote (Poll) has gone out to all EMCO TSC Representatives to approve the amendments on this page.

    7 approve votes are needed to pass (quorum).