1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
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
|
