diff options
Diffstat (limited to 'fluent-bit/lib/wasm-micro-runtime-WAMR-1.2.2/TSC_Charter.md')
| -rw-r--r-- | fluent-bit/lib/wasm-micro-runtime-WAMR-1.2.2/TSC_Charter.md | 168 |
1 files changed, 168 insertions, 0 deletions
diff --git a/fluent-bit/lib/wasm-micro-runtime-WAMR-1.2.2/TSC_Charter.md b/fluent-bit/lib/wasm-micro-runtime-WAMR-1.2.2/TSC_Charter.md new file mode 100644 index 000000000..56c4a024b --- /dev/null +++ b/fluent-bit/lib/wasm-micro-runtime-WAMR-1.2.2/TSC_Charter.md @@ -0,0 +1,168 @@ +# 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: + +* [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 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. + +[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 + |