edb184f709
Remove unnecessary functions and implement more APIs: - wasm_##name##same - wasm##name##as_ref - wasm_ref_as##name## - wasm_ref_delete - wasm_module_validate - wasm_table_get/set/size - wasm_memory_size - wasm_config_new - wasm_foreign_new And add more wasm-c-api samples, update the related documen, add more CI rules. Signed-off-by: Wenyong Huang <wenyong.huang@intel.com>
7.3 KiB
Project Technical Steering Committee (PTSC) Charter
Section 1. Guiding Principle
The WebAssembly Micro Runtime (WAMR) project is part of the Bytecode Alliance (BA) which operates 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 under Bytecode Alliance
Technical leadership for the WAMR projects within the Bytecode Alliance is delegated to the projects through the project charter. Though the BA TSC will not interfere with day-to-day discussions, votes or meetings of the PTSC, the BA TSC may request additional amendments to the PTSC charter when there is misalignment between the project charter and the BA mission and values.
The PTSC structure described in this document may be overhauled as part of establishing a BA TSC in order to adhere to constraints or requirements that TSC will impose on project-level governance.
Section 3. Establishment of the PTSC
PTSC memberships are not time-limited. There is no maximum size of the PTSC. 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 PTSC must have at least four members.
There is no specific set of requirements or qualifications for PTSC membership beyond these rules. The PTSC may add additional members to the PTSC by a standard PTSC motion and vote. A PTSC member may be removed from the PTSC by voluntary resignation, by a standard PTSC motion, or in accordance to the participation rules described below.
Changes to PTSC membership should be posted in the agenda, and may be suggested as any other agenda item.
The PTSC may, at its discretion, invite any number of non-voting observers to participate in the public portion of PTSC discussions and meetings.
The PTSC shall meet regularly using tools that enable participation by the community (e.g. weekly on a Zulip channel, or through any other appropriate means selected by the PTSC ). The meeting shall be directed by the PTSC Chairperson. Responsibility for directing individual meetings may be delegated by the PTSC Chairperson to any other PTSC member. Minutes or an appropriate recording shall be taken and made available to the community through accessible public postings.
PTSC members are expected to regularly participate in PTSC activities.
In the case where an individual PTSC member -- within any three month period -- attends fewer than 25% of the regularly scheduled meetings, does not participate in PTSC discussions, and does not participate in PTSC votes, the member shall be automatically removed from the PTSC. The member may be invited to continue attending PTSC meetings as an observer.
Section 4. Responsibilities of the PTSC
Subject to such policies as may be set by the BA TSC, the WAMR PTSC 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 PTSC will define WAMR project’s release vehicles.
Section 5. WAMR Project Operations
The PTSC 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 PTSC review (e.g. agenda items must be published at least a certain number of hours in advance of a PTSC meeting).
The PTSC and entire technical community will follow any processes as may be specified by the Bytecode Alliance Board relating to the intake and license compliance review of contributions, including the Bytecode Alliance IP Policy.
Section 6. Elections
Leadership roles in the WAMR project will be peer elected representatives of the community.
For election of persons (such as the PTSC Chairperson), a multiple-candidate method should be used, such as:
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 PTSC will elect from amongst voting PTSC members a PTSC Chairperson to work on building an agenda for PTSC meetings. The PTSC shall hold annual
elections to select a PTSC Chairperson; there are no limits on the number of terms a PTSC Chairperson may serve.
Section 7. Voting
For internal project decisions, Collaborators shall operate under Lazy Consensus. The PTSC shall establish appropriate guidelines for implementing Lazy Consensus (e.g. expected notification and review time periods) within the development process.
The PTSC 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 PTSC 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 PTSC or else the discussion will continue.
For all votes, a simple majority of all PTSC members for, or against, the issue wins. A PTSC member may choose to participate in any vote through abstention.
Section 8. Project Roles
The WAMR git repository is maintained by the PTSC and additional Collaborators who are added by the PTSC 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 PTSC and their addition as Collaborators is discussed during a PTSC 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 PTSC
for discussion by assigning the tsc-agenda tag to a pull request or
issue. The PTSC should serve as the final arbiter where required. The PTSC
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 PTSC. Contributors should rarely be encumbered by the PTSC.
-
Project: a technical collaboration effort, e.g. a subsystem, that is organized through the project creation process and approved by the PTSC.