This document was approved by the CoSAI PGB, 21 August 2024. Further updates were approved by the PGB on 22 October 2025.
The TSC is responsible for the overall technical health and direction of the project and advises the PGB on such matters. Further, the TSC is responsible for releases and overseeing work of Workstreams, WS Chairs, Contributors, and Maintainers.
The TSC reports to the PGB and is subject to the CoSAI Governance.
The CoSAI TSC members follow the OASIS Participants Code of Conduct and work in accordance with the OASIS Open Project Rules.
The CoSAI Open Project maintains a no-solicitation policy covering all meetings, webinars, and other events. Additionally, it is expected that participation in this Open Project will not result in future solicitations unless specifically invited.
Any violations to the Code of Conduct or rules of collaboration can be brought to the Open Project Administrator.
Premier Sponsors and Founding Sponsors will have the option for one TSC Representative. This person may be different from the PGB representative and should be a subject matter expert.
The TSC will be populated by the following process:
- TSC members and TSC alternates representing Premier Sponsors and Founding Sponsors are selected by that sponsoring member as they know their talent the best. This person can be switched out with prior notice to the PGB and OASIS staff. The TSC representative should designate no more than one alternate.
- Appointment of the non-sponsor seats to the TSC is done by a consensus vote by the PGB. The maximum number of non-sponsor seats will be determined by the number of active CoSAI workstreams, with a maximum of one non-sponsor seat per workstream. Currently, this number is three with three active workstreams. There will be a minimum of two non-sponsor seats total. Total number of non-sponsor seats is reviewed upon the addition or closing of CoSAI workstreams. It is encouraged that each workstream has at least one non-sponsors TSC member.
The PGB can adjust the process for populating the TSC once the membership number normalizes and will review this rule on TSC membership eligibility, including non-sponsor seats, on an annual basis.
No legal entity shall hold more than one voting seat on the TSC.
The TSC has at least two Co-Chairs elected by the TSC with a Full Majority Vote and the TSC has to select one member to represent it on the PGB. The TSC shall select the representative to the PGB from the non-sponsoring seats, in order to avoid any one organization having two votes on the PGB. This representative is a voting expert representative of the TSC per the OASIS Rules.
The Co-Chairs are elected or re-confirmed every two years by a Full Majority Vote of the TSC. Existing Chairs serve until they resign or are replaced in an election. The PGB may also remove a TSC Chair at any time with a Full Majority Vote.
All TSC members are expected to attend the committee meetings on a regular basis and contribute to the objectives and outcomes of those meetings.
Every TSC member should be involved in at least one workstream.
The TSC in coordination with the PGB, is responsible for setting a roadmap for each Workstream. The PGB is expected to provide a workstream scope and vision which enables the TSC to utilize their subject matter expertise to determine the path toward completion. The TSC then oversees the implementation of the roadmap by the individual workstream leads, ensuring its successful execution.
The purpose of the workstreams is to divide up the work of the open project into manageable work packages. Workstreams will be determined by the PGB and shared with the TSC for execution.
Workstream contributors can also propose amendments to the scope and deliverables for their workstream to the TSC. This feedback may be communicated by the Workstream Lead.
Workstream Leads are selected by the TSC via lazy consensus when the workstream is formed, and reconfirmed annually. Workstream Leads are not required to be part of a sponsoring organization.
Workstream Lead responsibilities include:
- Facilitation of WS meetings including setting an agenda, capturing minutes and following up on action items
- Ensure that progress is made on work assigned to the WS
- Facilitate voting as needed - OASIS staff can assist
- Responsible for keeping the WS on track with regard to the roadmap set by the TSC
- Accountable for GitHub Repo management including edits/updates, issue and PR backlog management, and delegating responsibility to a separate volunteer, if applicable
- Workstream Chairs report to the TSC on a regular basis about the progress of the WS.
WS leads should aim to schedule meetings at times that allow for the highest possible attendance from most members.
Each Workstream will have one or more Github repositories. The repositories are managed by both WS leads and CoSAI Maintainers.
Every WS will have a dedicated mailing list. The mailing lists have public archives, (potential) contributors (see below) can apply to join the mailing lists. The WS mailing lists are moderated by the WS leads and Maintainers.
In addition to those represented on the TSC, anyone in the CoSAI community that contributes code, documentation or other technical artefacts to any of the workstreams, is a CoSAI Contributor. Every contributor is required to sign a Contributor License Agreement (CLA).
All technical and standards-related work of each workstream is maintained publicly in the Github repositories of the individual workstreams.
Anyone can get involved and start contributing by requesting to join a WS mailing list, attending WS meetings, submitting an issue or a PR to a repository, or by participating in other official project tool.
In general, a CoSAI Contributor is expected to:
- Be knowledgeable in one or more fields related to the project
- Show commitment over time with one or more PRs merged
- Contribute to the developing and finalizing the WS deliverables outlined in this document
- Be reliable in completing issues to which they have been assigned
- Attend WS meetings on a regular basis
- Follow the project style and testing guidelines
- Be welcoming to others in the community who are using the project
- Contribute in ways that substantially improve the quality of the project and the experience of people who use it
- Follow branch, PR, and code style conventions
WS Contributors must conform with legal requirements for CoSAI, see below.
The TSC is responsible for creating a contribution policy for the workstreams which can be approved by lazy consensus.
The TSC shall determine the number of maintainers required to merge a contribution into the master branch of the WS repo. This shall be done during the first TSC meeting. Changes to this number require a simple majority of TSC members.
The TSC will establish a maintainer policy which covers the number of maintainers per repository. The Workstream Leads should also serve as the maintainer for the relevant repositories.
Loss of Voting Rights: A TSC member will lose their voting right at the end of the second consecutive TSC meeting missed where neither the member nor their designated alternate is present, without prior notice to the TSC Chair. In such instances, the member will also not be counted towards quorum in a TSC meeting. However, they shall retain all other rights, privileges, and obligations afforded to TSC members. The corresponding PGB representative will also be notified. If the TSC member is located in a timezone that makes it difficult to attend the meetings, they can notify the TSC chairs and OASIS staff, and their non-participation will not be counted. Meeting recordings will be shared so these members can comment on discussion items asynchronously. The TSC chairs should aim to schedule meetings at times that allow for the highest possible attendance from most members
Regaining Voting Rights: A TSC member who has lost their voting rights by missing two meetings may regain voting rights by (a) declaring to the Chair their desire to regain voting rights and then (b) attending (or having their alternate attend) two consecutive meetings of the TSC. Their rights will be restored at the end of the second meeting.
The TSC and Workstreams are encouraged to work asynchronously using provided tools such as the email list, GitHub repositories, and other tools as requested. Furthermore, these groups are suggested to use lazy consensus where possible, for the exception of where formal ballots are required by the OASIS Open Project Rules.
Major changes on Github or to a WS document using any other official project platform should be accompanied by a post on the WS mailing list, the relevant WS Slack channel and should also be announced in workstream meetings as appropriate. Author(s) of the change proposal, Pull request, or issues should give a time period of at least 7 working days for comments.
Lazy consensus is practiced for all projects and documents, including the main project repository and draft documents using other tools than Github.
Lazy consensus does not apply to decisions regarding finalizing a WS deliverable or work product and moving a specification to the OASIS standards track.
When a WS completes a deliverable or work product that it wants approved as an official release, it is expected that workstream leads will have secured agreement among the workstream contributors before raising the deliverable for approval by the TSC. When the WS leads agree on the approval of the work product, they should request a 5-day review by the TSC and the PGB at the same time, followed by a Full Majority Vote of the TSC. Once the TSC approval is confirmed, the TSC will request approval from the PGB. The PGB will then start a call for consensus (3-5 days). A specified majority vote may be requested.
A TSC member or Workstream member is eligible to lose their seat for violating the Code of Conduct. Violations of the Code of Conduct may be reported to OASIS Staff at code-of-conduct@oasis-open.org. If OASIS staff determines that a violation of the Code of Conduct has occurred, the TSC can decide if they want to remove the person in question via a Full Majority Vote.
In case of removal of a TSC member, the PGB will select a new member according to the process outlined above.
TSC and Workstream members and contributors must abide by the OASIS Open Projects IPR Policy and the Apache 2.0 License agreement as well as the CC-BY 4.0 license agreement as outlined in the license.md files for each repository.
TSC and Workstream members and contributors must have signed and submitted a Contributor License Agreement (CLA) and patent non-assert for non-trivial contributions releasing all contributions under Apache2. If you have questions about these policies, please contact the OASIS Open Project Administrator.
All participants must also abide by the terms of the OASIS Open Projects Code of Conduct.
All substantive changes to this Charter require a Full Majority Vote of the TSC and subsequent approval with a Full Majority Vote of the PGB.