-
Notifications
You must be signed in to change notification settings - Fork 2
/
standardisation.html
478 lines (342 loc) · 27.2 KB
/
standardisation.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
<!doctype html>
<html>
<head>
<title>Standardisation · Solid</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1">
<link
rel="shortcut icon"
type="image/x-icon"
href="/favicon.ico?"
/>
<link rel="stylesheet" href="/assets/css/main.css" />
</head>
<body>
<header>
<nav class="navbar" role="navigation" aria-label="main navigation">
<div class="navbar-brand">
<a class="navbar-item" href="/">
<img
src="/assets/img/solid-emblem.svg"
alt="[Solid logo]"
/>
</a>
<a class="is-hidden-mobile navbar-item navbar-brand-name is-uppercase is-size-4" href="/">
Solid
</a>
</div>
<div class="navbar-menu">
<div class="navbar-end">
<a
class="navbar-item is-size-6 is-size-5-tablet"
href="/use-solid"
>使用Solid</a>
<a
class="navbar-item is-size-6 is-size-5-tablet"
href="/for-developers"
>开发人员</a>
<a
class="navbar-item is-size-6 is-size-5-tablet"
href="/for-enterprises"
>企业</a>
<a
class="navbar-item is-size-6 is-size-5-tablet"
href="/faqs"
>常见问题</a>
</div>
</div>
</nav>
</header>
<div id="draft-warning"></div>
<script>
if (document.location.hostname === 'localhost' || document.location.hostname === 'solid.github.io') {
const draftWarningElement = document.getElementById('draft-warning')
draftWarningElement.innerHTML = `
<div class="message is-danger is-large" role="alert">
<div class="message-body">
You are currently viewing a draft version of the Solid website. If you are looking for reliable information, visit the live site at <a href="https://solidproject.org/standardisation" title="The official Solid website">SolidProject.org</a>.
</div>
</div>
`;
}
</script>
<nav id="breadcrumb" class="breadcrumb">
<div class="container">
<ul>
<li>
<a href="/">
Home
</a>
</li>
<li>
<a href="">
Standardisation
</a>
</li>
</ul>
</div>
</nav>
<main>
<div class="container">
<div class="columns">
<div class="column is-two-thirds">
<article class="section content">
<p>You can read the <a href="https://solid.github.io/specification/">Solid Specification</a> and the details of <a href="https://github.com/solid/process">how to participate in the standardisation process</a> here.</p>
<p>Please read the <a href="#conduct">Code of Conduct</a> before doing so.</p>
<p>Tune into the following calls to participate:</p>
<ul>
<li><a href="https://github.com/solid/process/blob/master/panels.md#authentication">Authentication Panel</a> on Mondays at 1600 CET on <a href="https://hangouts.google.com/call/3k5z3gBVKm-58m8Xgm2YAEEE">this line</a></li>
<li><a href="https://github.com/solid/process/blob/master/panels.md#data-interoperability-and-portability">Data Interoperability and Portability Panel</a> on Mondays at 2130 CET on <a href="https://global.gotomeeting.com/join/620786365">this line</a></li>
<li><a href="https://github.com/solid/process/blob/master/panels.md#authorization-and-access-control">Authorization and Access Control Panel</a> on Wednesdays at 1600 CET on <a href="https://hangouts.google.com/call/vsPFdfBxsTgfHcjKbmcXAEEE">this line</a></li>
<li>Test Suite on Wednesdays at 1530 CET on <a href="https://whereby.com/solid-test-suit">this line</a></li>
<li>There is a weekly W3C Solid Community Group call to review all panels on Thursdays alternating between 1000 CET and 1600 CET on <a href="https://zoom.us/j/121552099">this line</a>. The 28th November 2019 will be at 1000 CET.</li>
</ul>
<p>There are two ways of contributing to Solid:</p>
<ul>
<li>Panellists: draft theme based proposals with other panellists to improve Solid</li>
<li>Editors: review theme based proposals put forward by panellists</li>
</ul>
<h2 id="contributors">Contributors</h2>
<p>Any individual that has been involved in proposals to improve the <a href="https://github.com/solid/specification">Solid Specification</a> has provided a valuable service to the <a href="https://www.solidproject.org">Solid Project</a> and is encouraged to continue.</p>
<p>All manner of contributions are important - whether identifying problems, asking questions, or proposing normative changes.</p>
<p>There are many topics, problems, or ideas best tackled by a group of people with a specific set of domain expertise. For these cases, we have <a href="#solid-panels">Solid Panels</a>.</p>
<h3 id="solid-panels">Solid Panels</h3>
<p>Solid Panels are groups of individuals focused on a specific problem or domain relevant to Solid, with an aim to propose changes to the <a href="https://github.com/solid/specification">Solid Specification</a>. Anyone may join a panel or suggest a new panel.</p>
<p>Domains may be technical, non-technical, or some combination of the two. For example, a Security Panel could focus on the evaluation and advancement of the Solid security model.</p>
<p>A list of Solid Panels is maintained at <a href="https://github.com/solid/process/blob/master/panels.md">panels.md</a>. This listing helps people find panels they may want to participate in, and helps editors find panels to consult as part of the editorial process.</p>
<p>Panels may request to have a repository created within the <a href="https://github.com/solid">Solid GitHub Organization</a>. These requests should be made by submitting an issue to <a href="https://github.com/solid/process">solid/process</a>. The request should include the proposed name of the repository, and how it will be used. Any editor may reject a proposed name and request an alternative. All panel members will receive <a href="https://help.github.com/en/articles/repository-permission-levels-for-an-organization#permission-levels-for-repositories-owned-by-an-organization"><em>Maintain Permissions</em></a> on the panel repository, unless it is subject to editorial review, which would require that it employ a <a href="#repositories">different permission structure</a>. Panel repositories that are inactive for more than six months may be archived by Solid Administrators.</p>
<p>Panels may request to have a Gitter channel created within the <a href="https://gitter.im/solid">Solid Gitter Organization</a>. These requests should be made by submitting an issue to <a href="https://github.com/solid/process">solid/process</a>.</p>
<h2 id="stakeholders">Stakeholders</h2>
<p>Stakeholders are those affected by normative changes to the <a href="https://github.com/solid/specification">Solid Specification</a>. There are two types of Stakeholders; <a href="#solid-users">Solid Users</a> and <a href="#implementers">Solid Implementers</a>. It is important to consider them both when proposing changes, and adhering to the W3C <a href="https://www.w3.org/TR/html-design-principles/#priority-of-constituencies">priority of constituencies</a> is encouraged. A Stakeholder may be both a user and an implementer.</p>
<p>Stakeholders who have opted to identify themselves publicly are listed at <a href="https://github.com/solid/process/blob/master/stakeholders.md">stakeholders.md</a>. Anyone may decide to identify themselves publicly as a Solid Stakeholder, but it is not mandatory. Identified stakeholders may be consulted for feedback as part of the editorial process.</p>
<h3 id="solid-users">Solid Users</h3>
<p>Solid Users are individuals, companies, or organizations who access data stored in a Solid Pod.</p>
<h3 id="implementers">Implementers</h3>
<p>Solid Implementers are companies or organizations who are implementing the <a href="https://github.com/solid/specification">Solid Specification</a>. A Solid Implementer may be any combination of Identity Provider, Pod Provider, and Application Provider.</p>
<h2 id="how-to-make-changes">How to Make Changes</h2>
<p>This section details how changes to the <a href="https://github.com/solid/specification">Solid Specification</a> may be drafted, proposed, and accepted.</p>
<p>Anyone may submit a proposal to alter this process. These proposals will not be reviewed by the editors. They will be reviewed only by <a href="https://github.com/timbl">Tim Berners-Lee</a>, who is the Solid Director.</p>
<h3 id="drafting-proposals">Drafting proposals</h3>
<p>Anyone may propose improvements to the <a href="https://github.com/solid/specification">Solid Specification</a>. Here are some examples of different ways to contribute:</p>
<ul>
<li>Submit a pull request or issue on the <a href="https://github.com/solid/solid-spec">Solid Specification repository</a> in GitHub</li>
<li>Make a suggestion to the Solid Authorization Panel chat room about a change you’d like to see in Web Access Control</li>
<li>Make a suggestion on the Solid W3C Community Group mailing list to form a new Solid Panel, or join an existing Solid Panel</li>
<li>Propose an item for the W3C Solid Community Group call</li>
</ul>
<p>Proposals for substantive changes to the <a href="https://github.com/solid/specification">Solid Specification</a> go through an editorial review process. A change is considered substantive when it alters the normative text of the Solid Specification or the Solid Roadmap. Any proposal must be realistic and reasonable to implement, preferably with example implementations, and demonstrable support from Implementers.</p>
<p>Any proposal should also be accompanied with a reasonable explanation of the need for the proposed change. For example:</p>
<ul>
<li>Adding a new capability that satisfies one or more new use cases, or to reflect a new capability already incorporated consistently into multiple implementations.</li>
<li>Removing something because it was never adopted by Implementers for legitimate reasons, or because there has been a collective shift in focus away from that feature and it no longer makes sense to keep it.</li>
<li>Changing something to a simpler design that is able to address the same use case(s) with less complexity, or a change that resolves one or more identified issues in real-world use.</li>
</ul>
<p>A draft proposal often involves public discussion before being formally presented for review. After these discussions have occurred and a draft proposal has reached a sufficient level of maturity, it should be presented as a candidate proposal, asking Stakeholders and Panels if there are any major objections.</p>
<p>When there are objections, notify the Solid Panels and Stakeholders about the final proposal with an invitation to vote. If there are options, detail them along with the implications of the options. The final proposal needs to be open for one week to give others a chance to vote. To show your support for a proposal write +1. To show your disapproval for a proposal write -1 along with a detailed reason for the disapproval and a suggestion for a preferred alternative. To abstain type 0 when you have no opinion. If you do not vote by the end of the week it will be assumed that you abstain. At the end of the week anyone may publish an overview of the vote results per Solid Panel and Stakeholder.</p>
<h3 id="reviewing-proposals">Reviewing proposals</h3>
<p>Candidate proposals to the <a href="https://github.com/solid/specification">Solid Specification</a> submitted for review go through an editorial process before they are accepted.
Candidate Proposals to change the Solid Specification must be submitted for editorial review before they are accepted, along with the results of any votes taken.</p>
<p>An Editor determines whether a Candidate Proposal includes a substantive change and marks it accordingly. If there is any disagreement among Editors, the Candidate Proposal will be automatically marked as including a substantive change.</p>
<p>Candidate Proposals with substantive changes require three Editors who are assigned to the material being modified to actively approve the proposal, with no Editors from the Editorial Team actively rejecting. If there are less than three Editors assigned to the material being modified, then other Editors from the Editorial Team may participate. Editors may abstain. Candidate Proposals with substantive changes must remain open for at least one week before final acceptance. If an Editor does not vote by the end of that week it will be assumed that they abstained, providing a good faith attempt has been made to involve those who may be likely to disagree. Once the Candidate Proposal has successfully passed editorial review and the specified wait-time has elapsed, it may be merged by an assigned Editor.</p>
<p>Candidate Proposals without substantive changes require one Editor assigned to the material being modified to actively approve the proposal, with no Editors from the Editorial Team actively rejecting, and may be merged immediately by an assigned Editor. An assigned Editor may approve and merge their own non-substantive changes. Anyone from the Editorial Team has the right to revert a non-substantive change, but are encouraged to communicate with the assigned Editor that merged it first. Any revert must be accompanied by a reasonable explanation. If the change is reverted because they believe it to be substantive, that must be included in the explanation.</p>
<h2 id="editorial-structure">Editorial Structure</h2>
<p>Editor appointments and their respective assignments are made by the Solid Director. The Editorial Team is comprised of all the Editors appointed by the Solid Director, who are listed at <a href="https://github.com/solid/process/blob/master/editors.md">editors.md</a>, along with their assignments, contact details, and affiliations. Anyone may apply to be an Editor, and must include one or more requested editorial assignments as part of their application. These requests are not reviewed by other Editors. They are reviewed only by the Solid Director. Editor applications that can demonstrate the support of a relevant panel or group of community members will be favorably considered.</p>
<p>Editors belong to the <a href="https://github.com/orgs/solid/teams/editors">Editorial Team</a> in the <a href="https://github.com/solid">Solid GitHub Organization</a>.</p>
<h3 id="repositories">Repositories</h3>
<p>Repositories requiring editorial review are listed in <a href="https://github.com/orgs/solid/teams/editors#editorial-assignments">there</a>. Each repository has one or more assigned editors, and only assigned editors are permitted to merge into the master branch of these repositories, per the <a href="#reviewing-proposals">proposal review process</a>.</p>
<p>Editors have <a href="https://help.github.com/en/articles/repository-permission-levels-for-an-organization#permission-levels-for-repositories-owned-by-an-organization"><em>Admin Permissions</em></a> on the repositories they are assigned to, and are permitted to grant <a href="https://help.github.com/en/articles/repository-permission-levels-for-an-organization#permission-levels-for-repositories-owned-by-an-organization"><em>Write Permissions</em></a> to other contributing authors on the same. All members of the Editorial Team have <a href="https://help.github.com/en/articles/repository-permission-levels-for-an-organization#permission-levels-for-repositories-owned-by-an-organization"><em>Write Permissions</em></a> on all repositories requiring editorial review listed in <a href="https://github.com/solid/process/blob/master/editors.md">editors.md</a>.</p>
<h1 id="code-of-conduct"><a id="conduct"></a>Code of Conduct</h1>
<p>Personal threats or discriminatory threats towards arbitrary groups on Solid Gitter, Solid forum, or the W3C Solid Community Group call and mailing list may result in a ban of the threatening individual by the Solid Manager.</p>
<p>Repeated and sustained straying from the <a href="https://github.com/solid/information#connect">defined aims of the Solid Gitter channels</a> may result in a ban of those individuals straying from those defined aims by the Solid Manager.</p>
<h2 id="general-expectations">General Expectations</h2>
<p>Below are some general expectations around how participants of the Solid community are encouraged to behave.</p>
<p>Participants in the Solid community are expected to behave professionally and respectfully. This community is committed to maintain a positive and constructive community while helping to build Solid. This commitment calls for a community where participants behave according to the rules of the following Code of Conduct:</p>
<ul>
<li>Communicate and behave with respect, professionalism, fairness, and sensitivity.</li>
<li>Communicate constructively and avoid demeaning or insulting behavior or language.</li>
<li>Be welcoming. We strive to be a community that welcomes and supports people of all backgrounds and identities. This includes, but is not limited to, members of any race, religion, national origin, sexual orientation, gender identity and expression, and physical and mental abilities.</li>
<li>Be mindful of people’s time and effort spent on contributions to the project. In discussions, read other people’s points, make an effort to understand, and reply to relevant statements and questions they write. Substantiate your opinions, concerns, or issues respectfully with arguments of an appropriate technical level to keep the discussion clear and focused.</li>
<li>Do not insult or put down other participants. Harassment (whether verbal, physical or sexual) and other exclusionary behavior is not acceptable.</li>
<li>Disagreements, both social and technical, happen all the time. Whenever inappropriate behaviors are observed members of the community should strive to bring the discussion back to a more professional level. In most cases misunderstandings and disagreements can be resolved informally. Do not hesitate to <a href="mailto:[email protected]">contact</a> the Solid Manager if you feel that your concerns are not being sufficiently addressed. We hope that most concerns can be solved this way. However, if one person believes another’s behavior is inappropriate (inconsistent with the Code of Conduct or the good working of the group), and ordinary communication between them is not possible, escalation of the issue can take place by <a href="mailto:[email protected]">contacting</a> the Solid Manager. They may temporarily or permanently ban an individual from participating in activities, e.g. in a chat, mail or in Git for acting against the Code of Conduct.</li>
</ul>
<h2 id="best-practices">Best Practices</h2>
<p>Best practices for the Solid Community include:</p>
<ul>
<li>Contribute! Help Solid be the best it can be. Work together constructively toward the good working of the technology.</li>
<li>Stay on topic. Remember others voices need to be heard as well as yours and you must allow the space for other members to participate (e.g. don’t monologue or respond to every comment).</li>
<li>Respect the expertise and contributions of other members of the community (e.g. don’t assume that you’re “the smartest person in the room”). Remember that this is a community with different backgrounds who have valuable contributions to make.</li>
<li>Listen first and be sure you understand the point of view of the other person (e.g. don’t assume that others are disagreeing with you because they don’t understand what you’re saying and don’t suggest that another person’s comments are invalid because they have a different opinion).</li>
<li>Respond from an informed and inclusive point of view (e.g. don’t respond to comments without reading the background information).</li>
<li>Do review the work of others to see if you are doing something that other groups have already done (i.e. don’t “reinvent the wheel”).</li>
<li>Know that your contribution is still valuable even if it is not integrated.</li>
<li>Remember the work is about more than just your area of interest (e.g. don’t let your personal or professional goals impede the progress of the group).</li>
<li>Do <a href="mailto:[email protected]">contact</a> the Solid Manager if you feel someone has been working in a way that is having a negative impact on the work of the group, if they are insulting or harassing you, or unfairly impeding your own ability to work.</li>
<li>Maintain an open mindset and encourage others to do the same. There might be things you or others haven’t heard about yet, so be open to send and receive pointers to more info.</li>
<li>There are multiple ways of achieving the same goals, but when you build something new, check what already exists so we can better understand and help you with your contribution.</li>
</ul>
<h2 id="reporting-a-code-of-conduct-concern">Reporting a Code of Conduct Concern</h2>
<p>To report a code of conduct concern you may:</p>
<ul>
<li><a href="https://github.com/solid/process/issues/new">Submit an issue</a> to the solid/process GitHub repository</li>
<li>Contact the Solid Manager via Gitter</li>
<li>Email <a href="mailto:[email protected]">[email protected]</a></li>
<li>Write to the <a href="https://gitter.im/solid/chat">solid/chat</a> room on Gitter with your concern</li>
</ul>
<h2 id="based-on">Based on:</h2>
<ul>
<li>https://www.w3.org/Consortium/cepc/ (and an as-of-yet unpublished “Best
Practices for Working Groups”)</li>
<li>https://adainitiative.org/2014/02/18/howto-design-a-code-of-conduct-for-your-community/</li>
<li>http://geekfeminism.wikia.com/wiki/Code_of_conduct</li>
<li>https://www.djangoproject.com/conduct/</li>
<li>http://artofcommunityonline.org/Art_of_Community_Second_Edition.pdf</li>
</ul>
</article>
</div>
<aside id="sidebar" class="column is-one-third is-hidden-mobile section">
<div class="menu is-large">
<ul class="menu-list">
<li><a href="#contributors">Contributors</a>
<ul>
<li><a href="#solid-panels">Solid Panels</a></li>
</ul>
</li>
<li><a href="#stakeholders">Stakeholders</a>
<ul>
<li><a href="#solid-users">Solid Users</a></li>
<li><a href="#implementers">Implementers</a></li>
</ul>
</li>
<li><a href="#how-to-make-changes">How to Make Changes</a>
<ul>
<li><a href="#drafting-proposals">Drafting proposals</a></li>
<li><a href="#reviewing-proposals">Reviewing proposals</a></li>
</ul>
</li>
<li><a href="#editorial-structure">Editorial Structure</a>
<ul>
<li><a href="#repositories">Repositories</a></li>
</ul>
</li>
<li><a href="#general-expectations">General Expectations</a></li>
<li><a href="#best-practices">Best Practices</a></li>
<li><a href="#reporting-a-code-of-conduct-concern">Reporting a Code of Conduct Concern</a></li>
<li><a href="#based-on">Based on:</a></li>
</ul>
</div>
</aside>
</div>
</div>
</main>
<footer id="footer" class="footer">
<div class="container">
<div class="columns">
<div class="column">
<ul>
<li>
<a class="title is-size-5" href="/">首页</a>
</li>
<li>
<a class="is-size-5" href="/use-solid">使用Solid</a>
</li>
<li>
<a class="is-size-5" href="/implement">实现Solid</a>
</li>
<li>
<a class="is-size-5" href="/team">团队</a>
</li>
<li>
<a class="is-size-5" href="/faqs">常见问题</a>
</li>
</ul>
</div>
<div class="column">
<ul>
<li>
<span class="title is-size-5">最新消息</span>
</li>
<li>
<a class="is-size-5" href="/this-week-in-solid">Solid本周</a>
</li>
<li>
<a class="is-size-5" href="/press">新闻</a>
</li>
<li>
<a class="is-size-5" href="/events">Solid事件</a>
</li>
</ul>
</div>
<div class="column">
<ul>
<li>
<a class="title is-size-5" href="/for-developers">开发人员</a>
</li>
<li>
<a class="is-size-5" href="/for-developers/apps">写应用</a>
</li>
<li>
<a class="is-size-5" href="/for-developers/pod-server">运行Pod服务</a>
</li>
<li>
<a class="is-size-5" href="/funding">资金</a>
</li>
<li>
<a class="is-size-5" href="https://forum.solidproject.org">论坛</a>
</li>
</ul>
</div>
<div class="column">
<ul>
<li>
<span class="title is-size-5">更多</span>
</li>
<li>
<a class="is-size-5" href="/standardisation">标准化</a>
</li>
<li>
<a class="is-size-5" href="/license">许可</a>
</li>
<li>
<a class="is-size-5" href="/logo-usage-guidelines">图标使用指南</a>
</li>
<li>
<a class="is-size-5" href="https://github.com/solid/solidproject.org/issues/new">网站反馈</a>
</li>
</ul>
</div>
</div>
</div>
<nav class="navbar" role="navigation" aria-label="main navigation">
<div class="navbar-brand">
<a class="navbar-item" href="/">
<img
src="/assets/img/solid-emblem.svg"
alt="[Solid logo]"
/>
</a>
<a class="navbar-item" href="mailto:[email protected]">
</a>
<a class="navbar-item" href="https://github.com/solid/" title="Solid on GitHub">
<span class="image is-24x24">
<img
src="/assets/img/fontawesome-free-5.11.2-web/svgs/brands/github.svg"
alt="GitHub"
class="brand-icon"
/>
</span>
</a>
<a class="navbar-item" href="https://twitter.com/project_solid" title="Solid on Twitter">
<span class="image is-24x24">
<img
src="/assets/img/fontawesome-free-5.11.2-web/svgs/brands/twitter.svg"
alt="Twitter"
class="brand-icon"
/>
</span>
</a>
</div>
</nav>
</footer>
</body>
</html>