/
games-cg-2020.html
304 lines (298 loc) · 13.6 KB
/
games-cg-2020.html
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
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
<!DOCTYPE html>
<html lang="en">
<head>
<title>
Games Community Group Charter
</title>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width">
<link rel="stylesheet" href="//www.w3.org/StyleSheets/TR/base">
<style>
body {
max-width: 60em;
margin: auto;;
}
*:target {
background-color: yellow;
}
li {
margin-bottom: 9pt;
}
.note {
background-color: yellow;
padding: 10px;
}
.remove {
background-color: yellow;
}
</style>
</head>
<body>
<h1>
<span class="remove">[PROPOSED]</span> Games Community Group Charter
</h1>
<p class="note">
This Charter is work in progress. To submit feedback, please use
<a href="https://github.com/w3c/charter-drafts/issues">GitHub Issues</a> where this
Charter is being developed.
</p>
<ul>
<li>This Charter: <span class="remove">{TBD: URI}</span>
</li>
<li>Start Date: <span class="remove">{TBD: date the charter takes effect}</span>
</li>
</ul>
<h2 id="goals">
Goals
</h2>
<p>
The goal of the Games Community Group is to improve the quality of open
web standards that games developers rely on to create games.
</p>
<h2 id="scope-of-work">
Scope of Work
</h2>
<p>
To achieve its goal, the Games community group will:
</p>
<ul>
<li>Track specifications and vendor implementations related to open web
games.</li>
<li>Recommend new specifications to be produced and find group homes
for them.</li>
<li>Refine use cases to communicate specific needs of games.</li>
<li>Suggest refinements or fixes to existing specifications to better meet
the needs of the game development community.</li>
<li>Explore capabilities —APIs, semantics, techniques for rendering, processing, personalization, customization, interoperability, etc.— that developers can leverage to localize games and guarantee that they are accessible.</li>
<li>Evangelize specifications to browser vendors.</li>
<li>Document how to best use open web standards for games.</li>
<li>Evangelize open web standards to game developers and game development
best practices to web developers.</li>
</ul>
<p>The Games community group will not develop any normative specification.
As such, there will not be any Essential Claims under the W3C Contributor
License Agreement or Final Specification Agreement.</p>
<h2 id="deliverables">
Deliverables
</h2>
<h3 id="specifications">
Specifications
</h3>
<p>
No Specifications will be produced under the current charter.
</p>
<h3 id="non-normative-reports">
Non-Normative Reports
</h3>
<p>
The group may produce other Community Group Reports within the scope of
this charter but that are not Specifications, for instance use cases,
requirements, or white papers.
</p>
<h3 id="test-suites">
Test Suites and Other Software
</h3>
<p>
The group may develop open source software as needed to demonstrate
scenarios of interest, guidelines, and highlight possible gaps in web
technologies. Please see the GiHub LICENSE file for software contribution
licensing information.
</p>
<p>
The group will not develop Test Suites.
</p>
<h2 id="liaisons">
Dependencies or Liaisons
</h2>
<p>
By definition, this group will closely monitor ongoing standardisation
activities that are deemed useful in game scenarios. This includes those
identified during the
<a href="https://www.w3.org/2018/12/games-workshop/report.html">W3C
Workshop on Web games</a> (list is non-exhaustive):
</p>
<ul>
<li><a href="https://www.w3.org/WAI/APA/">Accessible Platform Architectures (APA) Working Group</a></li>
<li><a href="https://www.w3.org/2011/audio/">Audio Working Group</a> (and <a href="https://www.w3.org/community/audio-comgp/">companion Community Group</a>)</li>
<li><a href="https://www.ecma-international.org/memento/tc39.htm">ECMAScript TC39 Task Group</a></li>
<li><a href="https://www.w3.org/community/gpu">GPU for the Web Community Group</a></li>
<li><a href="https://www.khronos.org/">Khronos Group</a></li>
<li><a href="https://datatracker.ietf.org/wg/webtrans/about/">IETF WebTransport Working Group</a></li>
<li><a href="https://www.w3.org/immersive-web/">Immersive Web Working Group</a> (and <a href="https://www.w3.org/community/immersive-web/">companion Community Group</a>)</li>
<li><a href="https://www.w3.org/media-wg/">Media Working Group</a></li>
<li><a href="https://www.w3.org/community/miniapps/">MiniApps Ecosystem Community Group</a></li>
<li><a href="https://www.w3.org/2012/pointerevents/">Pointer Events Working Group</a></li>
<li><a href="https://www.w3.org/2019/webapps/">Web Applications Working Group</a></li>
<li><a href="https://whatwg.org/">Web Hypertext Application Technology Working Group (WHATWG)</a></li>
<li><a href="https://wicg.io/">Web Platform Incubator Community Group</a></li>
<li><a href="https://www.w3.org/wasm/">WebAssembly Working Group</a> (and <a href="https://www.w3.org/community/webassembly/participants">companion Community Group</a>)</li>
</ul>
<h2 id="process">
Community and Business Group Process
</h2>
<p>
The group operates under the <a href=
"https://www.w3.org/community/about/agreements/">Community and Business
Group Process</a>. Terms in this Charter that conflict with those of the
Community and Business Group Process are void.
</p>
<p>
As with other Community Groups, W3C seeks organizational licensing
commitments under the <a href=
'http://www.w3.org/community/about/agreements/cla/'>W3C Community
Contributor License Agreement (CLA)</a>. When people request to
participate without representing their organization's legal interests,
W3C will in general approve those requests for this group with the
following understanding: W3C will seek and expect an organizational
commitment under the CLA starting with the individual's first request to
make a contribution to a group <a href="#deliverables">Deliverable</a>.
The section on <a href="#contrib">Contribution Mechanics</a> describes
how W3C expects to monitor these contribution requests.
</p>
<p>
The <a href="https://www.w3.org/Consortium/cepc/">W3C Code of
Ethics and Professional Conduct</a> applies to participation in
this group.
</p>
<h2 id="worklimit">
Work Limited to Charter Scope
</h2>
<p>
The group will not publish Specifications on topics other than those
listed under <a href="#specifications">Specifications</a> above. See
below for <a href="#charter-change">how to modify the charter</a>.
</p>
<h2 id="contrib">
Contribution Mechanics
</h2>
<p>
Substantive Contributions to Specifications can only be made by Community
Group Participants who have agreed to the <a href=
"http://www.w3.org/community/about/agreements/cla/">W3C Community
Contributor License Agreement (CLA)</a>.
</p>
<p>
Specifications created in the Community Group must use the <a href=
"http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document">
W3C Software and Document License</a>. All other documents produced by
the group should use that License where possible.
</p>
<p>
Community Group participants agree to make all contributions on
public-facing tools chosen by the group (public mail list, GitHub
repositories, public discussion forum). For GitHub, this may be
in the form of a pull request (preferred), by raising an issue, or by
adding a comment to an existing issue.
</p>
<p id="githublicense">
All Github repositories attached to the Community Group must contain a
copy of the <a href=
"https://github.com/w3c/licenses/blob/master/CG-CONTRIBUTING.md">CONTRIBUTING</a>
and <a href=
"https://github.com/w3c/licenses/blob/master/CG-LICENSE.md">LICENSE</a>
files.
</p>
<h2 id="transparency">
Transparency
</h2>
<p>
The group will conduct all of its technical work in public. If the group
uses GitHub, all technical work will occur in its GitHub repositories
(and not in mailing list discussions). This is to ensure contributions
can be tracked through a software tool.
</p>
<p>
Meetings may be restricted to Community Group participants, but a public
summary or minutes must be posted to the group's public mailing list, or
to a GitHub issue if the group uses GitHub.
</p>
<h2 id="decision">
Decision Process
</h2>
<p>
This group will seek to make decisions where there is consensus. Groups
are free to decide how to make decisions (e.g. Participants who have
earned Committer status for a history of useful contributions assess
consensus, or the Chair assesses consensus, or where consensus isn't
clear there is a Call for Consensus [CfC] to allow multi-day online
feedback for a proposed course of action). It is expected that
participants can earn Committer status through a history of valuable
contributions as is common in open source projects. After discussion and
due consideration of different opinions, a decision should be publicly
recorded (where GitHub is used as the resolution of an Issue).
</p>
<p>
If substantial disagreement remains (e.g. the group is divided) and the
group needs to decide an Issue in order to continue to make progress, the
Committers will choose an alternative that had substantial support (with
a vote of Committers if necessary). Individuals who disagree with the
choice are strongly encouraged to take ownership of their objection by
taking ownership of an alternative fork. This is explicitly allowed (and
preferred to blocking progress) with a goal of letting implementation
experience inform which spec is ultimately chosen by the group to move
ahead with.
</p>
<p>
Any decisions reached at any meeting are tentative and should be recorded
in a GitHub Issue for groups that use GitHub and otherwise on the group's
public mail list. Any group participant may object to a decision reached
at an online or in-person meeting within 7 days of publication of the
decision provided that they include clear technical reasons for their
objection. The Chairs will facilitate discussion to try to resolve the
objection according to the <a href="#decision">decision process</a>.
</p>
<p>
It is the Chairs' responsibility to ensure that the decision process is
fair, respects the consensus of the CG, and does not unreasonably favour
or discriminate against any group participant or their employer.
</p>
<h2 id="chairs">
Chair Selection
</h2>
<p>
Participants in this group choose their Chair(s) and can replace their
Chair(s) at any time using whatever means they prefer. However, if 5
participants, no two from the same organisation, call for an election,
the group must use the following process to replace any current Chair(s)
with a new Chair, consulting the Community Development Lead on election
operations (e.g., voting infrastructure and using <a href=
"https://tools.ietf.org/html/rfc2777">RFC 2777</a>).
</p>
<ol>
<li>Participants announce their candidacies. Participants have 14 days to
announce their candidacies, but this period ends as soon as all
participants have announced their intentions. If there is only one
candidate, that person becomes the Chair. If there are two or more
candidates, there is a vote. Otherwise, nothing changes.
</li>
<li>Participants vote. Participants have 21 days to vote for a single
candidate, but this period ends as soon as all participants have voted.
The individual who receives the most votes, no two from the same
organisation, is elected chair. In case of a tie, RFC2777 is used to
break the tie. An elected Chair may appoint co-Chairs.
</li>
</ol>
<p>
Participants dissatisfied with the outcome of an election may ask the
Community Development Lead to intervene. The Community Development Lead,
after evaluating the election, may take any action including no action.
</p>
<h2 id="charter-change">
Amendments to this Charter
</h2>
<p>
The group can decide to work on a proposed amended charter, editing the
text using the <a href="#decision">Decision Process</a> described above.
The decision on whether to adopt the amended charter is made by
conducting a 30-day vote on the proposed new charter. The new charter, if
approved, takes effect on either the proposed date in the charter itself,
or 7 days after the result of the election is announced, whichever is
later. A new charter must receive 2/3 of the votes cast in the approval
vote to pass. The group may make simple corrections to the charter such
as deliverable dates by the simpler group decision process rather than
this charter amendment process. The group will use the amendment process
for any substantive changes to the goals, scope, deliverables, decision
process or rules for amending the charter.
</p>
</body>
</html>