forked from swicg/potential-charters
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathCGCharter-1727386911.html
485 lines (477 loc) · 20.6 KB
/
CGCharter-1727386911.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
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
<!DOCTYPE html>
<html lang="en">
<head>
<title>
{TBD: name} 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>
[DRAFT] Social Web Incubator Community Group Charter
</h1>
<p>
This Charter is work in progress. To submit feedback,
please use https://github.com/swicg/potential-charters/issues Issues
where Charter is being developed.
</p>
<ul>
<li>This Charter: <span class="remove">{TBD: URI}</span>
</li>
<li>Previous Charter: <span class="remove">{TBD: URI}</span>
</li>
<li>Start Date: <span class="remove">{TBD: date the charter takes effect,
estimate if not known. Update this if the charter is revised and include
a link to the previous version of the charter.}</span>
</li>
<li>Last Modifed: 2024-09-26
</li>
</ul>
<p>
The Social Web Incubator Community Group (also known as SocialCG, or
SWICG) is the successor of the Social Web Working Group, which ran from
2014 to 2017.
</p>
<h2 id="goals">
Goals
</h2>
<ul>
<li>
Provide space to collaborate and coordinate for implementors who are
building on any of the specifications published by the Social Web WG
(2014-2017), and related technologies.
</li>
<li>
Incubate new proposals which build on or complement the Social Web WG
recommendations.
</li>
</ul>
<h2 id="scope-of-work">
Scope of Work
</h2>
<p>
The group will maintain errata and corrected drafts, consisting of the published document with errata applied, for the following recommendations from the Social Web Working Group:
</p>
<ul>
<li>ActivityPub</li>
<li>Activity Streams 2.0 Core</li>
<li>Activity Vocabulary</li>
<li>Webmention</li>
<li>Linked Data Notifications</li>
<li>Micropub</li>
<li>WebSub</li>
</ul>
<p>
It will maintain errata and corrected drafts, consisting of the published document with errata applied, for the following Notes from the Social Web Working Group:
</p>
<ul>
<li>JF2</li>
<li>Post Type Discovery</li>
<li>Social Web Protocols</li>
<li>IndieAuth</li>
</ul>
<p>
The group will maintain the Activity Streams 2.0 JSON-LD context document and add new extension terms as they become widely implemented.
</p>
<p>
The group will maintain the Activity Streams 2.0 OWL ontology.
</p>
<p>
The group will develop extensions to ActivityPub and Activity Streams 2.0, and other specifications as needed, to address new use cases and requirements.
</p>
<p>
The group will develop and document integration between ActivityPub and other protocols, such as Webfinger, HTML, and HTTP Signature.
</p>
<p>
The group will develop and support the development of test suites and reference implementations for the above specifications and extensions.
</p>
<p>
The group will provide an interface and touchpoint for other W3C groups and external organizations working with these specifications.
</p>
<p>
The group will provide information for implementers of these specifications, including best practices, tutorials, and examples.
</p>
<h3 id="out-of-scope">
Out of Scope
</h3>
<p class="remove">
{TBD: Identify topics known in advance to be out of scope}
</p>
<h2 id="deliverables">
Deliverables
</h2>
<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 produce test suites to support the Specifications. Please
see the GitHub LICENSE file for test suite contribution licensing
information.
</p>
<h2 id="liaisons">
Dependencies or Liaisons
</h2>
<p class="remove">
{TBD: List any significant dependencies on other groups (inside or
outside W3C) or materials. }
</p>
<h2 id="process">
Community and Business Group Process
</h2>
<p>
The group operates under the <a href=
"https://www.w3.org/community/about/process/">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=
'https://www.w3.org/community/about/process/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
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=
"https://www.w3.org/community/about/process/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 in the
GitHub repo the group is using for the particular document. 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, e.g. on the <a
href="https://lists.w3.org/Archives/Public/public-swicg/">[email protected]
mailing list</a>,
<a href="https://www.w3.org/wiki/SocialCG">w3.org SocialCG wiki</a>, and
git repositories cloned in the <a
href="https://github.com/swicg">github.com/swicg/ Organization</a>
.
</p>
<p>
Meetings may be restricted to Community Group participants, but a public
summary or minutes must be posted to the <a
href="https://lists.w3.org/Archives/Public/public-swicg/">[email protected]
mailing list</a>.
</p>
<h2 id="decision">
Decision Process
</h2>
<p>
This group will seek to make decisions where there is consensus. The Group makes decisions in the following ways: either 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] (see below) 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
discursive 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>
To afford asynchronous decisions and organizational deliberation, any
resolution (including publication decisions) taken in a face-to-face
meeting or teleconference will be considered provisional.
A call for consensus (CfC) will be issued for all resolutions via
email to [email protected], preferably with the abbreviation CfC early
in the subject line to catch more attention.
</p>
<p>
Any group participant may object to a
decision reached at an online or in-person meeting within 14 days of
publication of the decision, provided that they include
clear reasons for their objection grounded in the scope and documented
goals of the CG and its work items.
</p>
<h3 id="calls-for-consensus">
Calls for Consensus
</h3>
<p>
The presence of formal resolutions will be indicated by a "CfC" prefix in
the subject line of an email on the list. Additional outreach to community
venues for more affirmative consent is strongly encouraged. There will be
a response period of 14 days. If no sustained objections are raised by the
end of the response period, the resolution will be considered to have
consensus as a resolution of the Community Group, i.e. a group decision.
All decisions made by the group should be considered resolved unless and
until new information becomes available or unless reopened at the
discretion of the Chairs or the Director.
</p>
<p>
The Chairs will facilitate discussion to try to resolve the
objection according to this decision process.
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">
Chairs
</h2>
<p>
The <a href="https://www.w3.org/Guide/chair/role.html">role of the Chair is described in the <a href="https://www.w3.org/Guide/">Art of Consensus</a>.
</p>
<p>
The Community Group participants elect (and/or other chairs appoint) no
fewer than One (1) and no more than Three (3) Chairs for the group at any
given time. The W3C Team Contact of the group SHOULD NOT be one of the
chairs at any point. Participation as Chair is afforded to the specific
individuals elected to those positions, and a participant"s seat MUST
NOT be delegated to any other person.
</p>
<p>
For most Chair nominees, the primary affiliation is their employer and
will match their affiliation in the W3C database. For contractors and
independents, this will normally be their contracting company or their
independent status; in some cases (e.g. where a consultant is consulting
for only one organization) this may be the organization for whom the
nominee is consulting.
<strong>Chair nominees, elected chairs, and appointed chairs MUST have
unique affiliations publicly stated at time of nomination, election (if it
has changed since last disclosure), or appointment.</strong>
Publicly stating additional or secondary affiliations is not required but
recommended. An organization with which one or more participants are
affiliated MAY submit one ballot that ranks candidates in their preferred
order as an organization as an informational exhibit; individual
participants should still vote explicitly, whether concurring or
dissenting with such an exhibit.
</p>
<h2 id="choosing-chairs">
Chair Selection
</h2>
<ul>
<li>
At any given time there may be up to three co-chairs, each holding one
seat. Each seat defines a 2 year cycle of service.
</li>
<li>
In the first election after ratification of this charter, all seats will
be up for election. Thereafter, in each year, a single election will be
held to fill any vacant seats.
</li>
<li>
In the case of interim vacancy, the remaining chairs may appoint a
co-chair for each open seat, hold an election for the same, or wait
until the next election, at their discretion. If the chairs do not take
any action, the seat will automatically be up for election in the next
cycle. Any such interim appointments or elections shall hold the seat
until the end of its natural cycle.
</li>
<li>
Reelection is restricted to two consecutive terms, with the possibility
of being reelected after sitting out one election cycle.
</li>
<li>
In an election year, current chairs will select a date for elections,
which will set a nomination period of two weeks, starting 4 weeks prior
to the election.
</li>
<li>
For an individual to run for election, they must self-nominate and make
a statement regarding their background and why they are running, on the
group mailing list.
</li>
<li>
The current chairs will host a conference call during the nomination
period, during which candidates may make a statement and answer
questions from the community.
</li>
<li>
If, at the end of nominations, any given seat only has a single
candidate, that candidate immediately wins that seat. For any seats with
multiple nominees, there will be an election for those seats.
</li>
<li>
If, after nominations, any given seat has no candidates, the remaining
chairs after any election (if necessary for other seats), will address
the vacancy as an interim vacancy, described above.
</li>
<li>
To elect one of multiple candidates, a vote will be held by the election
mechanism of ranked choice voting, in which voters rank candidates by
preference on their ballots. The candidate with the majority (more than
50%) of first-choice votes wins outright. If no candidate gets a
majority of first-choice votes, the candidate who ranked the worst is
eliminated, and that candidate"s voters" ballots are
redistributed to their second-choice pick. If the vote results in a tie,
an immediate runoff of the top two candidates shall be held. If the vote
remains tied, the winner shall be the candidate whose nomination was
first recorded publicly on the group email list.
</li>
</ul>
<h2 id="offboarding-chairs">
Chair Offboarding
</h2>
<ul>
<li>
A chair may voluntarily off-board at any given time; this should be done
publicly and on the mailing list.
</li>
<li>
Chairs may also be removed from their duties through a no-confidence
vote.
</li>
<li>
If a participant of the community group wishes to call for the recall of
a chair, for any reason, that participant must first privately
communicate with one or more of the other chairs
their desire and reason for doing so. Those chairs must give the
participant an opportunity to discuss their concerns with a goal of
resolving them. If, after 30 days, the participant feels their issues
have not been adequately addressed, they may then escalate to a public
call for a no-confidence vote (without having to disclose with whom they
have been discussing the matter). If, after 60 days, the participant has
not made a call for a no-confidence vote, the matter should be
considered dropped; any further attempts to remove the chair in question
must begin with a new round of private communication.
</li>
<li>
A public call for no-confidence must be announced to the group email
list stating the name of the chair subject to the recall. This
announcement must come from the participant who initiated the private
communication with the chairs to discuss their concerns. At least two
other supporting participants MUST reply to that email on the public
list within 48 hours to confirm their support for a no-confidence vote
of the chair in question.
</li>
<li>
The other chairs must acknowledge the call for no-confidence within 7
days of all three participants declaring their support.
</li>
<li>
UNLESS the chair in which no-confidence has been expressed voluntarily
offboards and opts out of the session on the mailing list, and within 30
days of a call for no-confidence, the other chairs MUST hold a
conference call at which the parties seeking no-confidence will have an
opportunity to present their case and participants of the group will be
able to ask clarifying questions. The chair in question SHALL NOT
moderate this call. They will, however, have equal time to respond
during that same call to the case made against them.
</li>
<li>
During the week following this conference call, participants may cast
votes in favor or against the recall by posting to the email list.
</li>
<li>
If affirmative votes cast that week (in favor of recall) comprise
greater than two-thirds of the total votes cast, then the chair in
question is removed and the seat shall be treated as an interim vacancy.
</li>
<li>
Participants are not required to vote. Abstentions may be recorded; such
abstentions shall not count towards the total number of votes when
calculating the two-thirds majority.
</li>
<li>
A Chair who has been removed may stand for reelection.
</li>
<li>
Only one call for no-confidence, for one chair, may be in process at any
given time. Priority shall be given to the first such vote to be
publicly called. Any subsequent public calls must wait until any
previous recalls are resolved, then must start with private
communication as described above.
</li>
</ul>
<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>