# WAMR Technical Steering Committee (WAMR-TSC) Charter ## Section 1. Guiding Principle The WebAssembly Micro Runtime (WAMR) project aims to operate transparently, openly, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders. ## Section 2. Project Governance The WAMR-TSC structure described in this document may be updated as part of the WAMR projects evolution. ## Section 3. Establishment of the WAMR-TSC WAMR-TSC memberships are not time-limited. There is no maximum size of the WAMR-TSC. The size is expected to vary in order to ensure adequate coverage of important areas of expertise, balanced with the ability to make decisions efficiently. The WAMR-TSC must have at least four members. There is no specific set of requirements or qualifications for WAMR-TSC membership beyond these rules. The WAMR-TSC may add additional members to the WAMR-TSC by a standard WAMR-TSC motion and vote. A WAMR-TSC member may be removed from the WAMR-TSC by voluntary resignation, by a standard WAMR-TSC motion, or in accordance to the participation rules described below. Changes to WAMR-TSC membership should be posted in the agenda, and may be suggested as any other agenda item. The WAMR-TSC may, at its discretion, invite any number of non-voting observers to participate in the public portion of WAMR-TSC discussions and meetings. The WAMR-TSC shall meet regularly using tools that enable participation by the community. The meeting shall be directed by the WAMR-TSC Chairperson. Responsibility for directing individual meetings may be delegated by the WAMR-TSC Chairperson to any other WAMR-TSC member. Minutes or an appropriate recording shall be taken and made available to the community through accessible public postings. WAMR-TSC members are expected to regularly participate in WAMR-TSC activities. In the case where an individual WAMR-TSC member -- within any three month period -- attends fewer than 25% of the regularly scheduled meetings, does not participate in WAMR-TSC discussions, *and* does not participate in WAMR-TSC votes, the member shall be automatically removed from the WAMR-TSC. The member may be invited to continue attending WAMR-TSC meetings as an observer. ## Section 4. Responsibilities of the WAMR-TSC Subject to such policies as may be set by the BA TSC, the WAMR WAMR-TSC is responsible for all technical development within the WAMR project, including: * Setting release dates. * Release quality standards. * Technical direction. * Project governance and process. * GitHub repository hosting. * Conduct guidelines. * Maintaining the list of additional Collaborators. * Development process and any coding standards. * Mediating technical conflicts between Collaborators or Foundation projects. The WAMR-TSC will define WAMR project’s release vehicles. ## Section 5. WAMR Project Operations The WAMR-TSC will establish and maintain a development process for the WAMR project. The development process will establish guidelines for how the developers and community will operate. It will, for example, establish appropriate timelines for WAMR-TSC review (e.g. agenda items must be published at least a certain number of hours in advance of a WAMR-TSC meeting). ## Section 6. Elections Leadership roles in the WAMR project will be peer elected representatives of the community. For election of persons (such as the WAMR-TSC Chairperson), a multiple-candidate method should be used, such as: * [Condorcet][] or * [Single Transferable Vote][] Multiple-candidate methods may be reduced to simple election by plurality when there are only two candidates for one position to be filled. No election is required if there is only one candidate and no objections to the candidate's election. Elections shall be done within the projects by the Collaborators active in the project. The WAMR-TSC will elect from amongst voting WAMR-TSC members a WAMR-TSC Chairperson to work on building an agenda for WAMR-TSC meetings. The WAMR-TSC shall hold annual elections to select a WAMR-TSC Chairperson; there are no limits on the number of terms a WAMR-TSC Chairperson may serve. ## Section 7. Voting For internal project decisions, Collaborators shall operate under Lazy Consensus. The WAMR-TSC shall establish appropriate guidelines for implementing Lazy Consensus (e.g. expected notification and review time periods) within the development process. The WAMR-TSC follows a [Consensus Seeking][] decision making model. When an agenda item has appeared to reach a consensus the moderator will ask "Does anyone object?" as a final call for dissent from the consensus. If an agenda item cannot reach a consensus a WAMR-TSC member can call for either a closing vote or a vote to table the issue to the next meeting. The call for a vote must be seconded by a majority of the WAMR-TSC or else the discussion will continue. For all votes, a simple majority of all WAMR-TSC members for, or against, the issue wins. A WAMR-TSC member may choose to participate in any vote through abstention. ## Section 8. Project Roles The WAMR git repository is maintained by the WAMR-TSC and additional Collaborators who are added by the WAMR-TSC on an ongoing basis. Individuals making significant and valuable contributions, “Contributor(s)”, are made Collaborators and given commit-access to the project. These individuals are identified by the WAMR-TSC and their addition as Collaborators is discussed during a WAMR-TSC meeting. Modifications of the contents of the git repository are made on a collaborative basis as defined in the development process. Collaborators may opt to elevate significant or controversial modifications, or modifications that have not found consensus to the WAMR-TSC for discussion by assigning the `tsc-agenda` tag to a pull request or issue. The WAMR-TSC should serve as the final arbiter where required. The WAMR-TSC will maintain and publish a list of current Collaborators, as well as a development process guide for Collaborators and Contributors looking to participate in the development effort. ## Section 9. Definitions * **Contributors**: contribute code or other artifacts, but do not have the right to commit to the code base. Contributors work with the project’s Collaborators to have code committed to the code base. A Contributor may be promoted to a Collaborator by the WAMR-TSC. Contributors should rarely be encumbered by the WAMR-TSC. * **Project**: a technical collaboration effort, e.g. a subsystem, that is organized through the project creation process and approved by the WAMR-TSC. [Consensus Seeking]: https://en.wikipedia.org/wiki/Consensus-seeking_decision-making [Condorcet]: https://en.wikipedia.org/wiki/Condorcet_method [Single Transferable Vote]: https://en.wikipedia.org/wiki/Single_transferable_vote