forked from frivoal/p2020
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
269 lines (246 loc) · 11.7 KB
/
index.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
<!DOCTYPE html>
<html lang="en">
<meta charset=UTF-8>
<meta content="width=device-width" name="viewport">
<title>Continuous Standards Development</title>
<link rel="stylesheet" href="template/AC-2020-slides.css">
<script src="template/shower.min.js" type="text/javascript"></script>
<style>
ul.nostyle > li::before {
content: "";
margin-left: 0;
}
</style>
<body class="shower fade-in">
<div class="progress">
<!-- Remove this element if you don't want a progress bar -->
</div>
<div class="slide cover clear" id='start'>
<h1>Process 2020</h1>
<address>Florian Rivoal (frivoal)<br>&Elika J. Etemad (fantasai)</address>
</div>
<div class='slide'>
<h1>Background</h1>
</div>
<div class='slide'>
<h1>Motivation: Problems</h1>
<ul>
<li><strong>Developing and evolving</strong> a Specification is currently difficult:
<ul>
<li>Complex specs spend years in CR without patent protection as details are refined prior to REC.
<li>Continuous development means tracking reality is a never-ending task. Declaring part of a spec as a REC by pulling out not-yet-normative features is obnoxious busywork to engineers who work on a continuous basis.
</ul>
<li><strong>Maintaining</strong> a Specification is currently difficult:
<ul>
<li>Bug fixes can appear at all times, and some may need to be addressed urgently (security fixes).
<li>Multiple transition requests and TR publications take extra time/resources, demotivating maintenance of RECs.
</ul>
</ul>
</div>
<div class="slide">
<h1>Motivation: Symptoms</h1>
<ul>
<li><strong>Out-of-date specifications</strong> hinder interoperability and understanding, yet many W3C specifications are either unmaintained, or maintained in unofficial publications, because posting official updates through the current Process is too burdensome.
<li>Work is shifting <strong>out of W3C Working Groups</strong> to Community Groups and WHATWG because of these maintenance problems.
</ul>
</div>
<div class='slide'>
<h1>Constraints: W3C Values</h1>
<ul>
<li>W3C values <strong>wide review</strong>, <strong>implementation experience</strong>, <strong>consensus</strong>, and <strong>royalty-free licensing</strong> as a means of developing well thought-out, implementable, and relevant specifications.
<li>Key <strong>role of the Process</strong> is to ensure these values are deeply incorporated into W3C’s standardization process.
<li>W3C Process needs to be a supportive framework that solicits excellence from both <strong>veteran standards experts</strong> as well as <strong>new participants and communities</strong> in a wide variety of industries; therefore needs both flexibility and formal structure.
</ul>
</div>
<div class='slide'>
<h1>Goals</h1>
<ul>
<li>Allow <strong>continuous development</strong> of specifications
<li><strong>Simplify maintenance</strong> of existing W3C Recommendations
<li>Secure <strong>patent commitments</strong> as soon as possible
<li><strong>Reduce overhead</strong>
<li>Continue the W3C commitment to <strong>Wide Review</strong> and <strong>consensus</strong>
</ul>
</div>
<div class='slide'>
<h1>Design Principles</h1>
<ul>
<li>Contents of a REC must fulfill the <strong>same requirements</strong> as currently.
<li>Maintain single Process track for normative specifications.
<li>Enable WGs to consistently maintain <strong>intended implementation target as official publications</strong> on w3.org/TR
<li>Wide review invites participation of the broader community, not just experts.
<li>Patent protection for early implementations and on continuously-developed specs.
<li>Improve on existing Process, don't rewrite from scratch.
</ul>
</div>
<div class='slide'>
<h1>Motivating Examples</h1>
<ol style='font-size: small'>
<li>ARIA: ARIA Mappings
<li>SVG: Beyond SVG 2
<li>WebAppSec: CSP
<li>Web Performance: performance timeline, …
<li>Web Platform: WebIDL
<li>Dataset Exchange: Beyond DCat 1.1
<li>Timed Text: TTML Profile registry
<li>Distributed Tracing: Trace Context Protocol Registry
<li>WebApps: Manifest, etc.
<li>Service Workers: Beyond SW 1
<li>CSS: 100 specifications and counting...
</ol>
</div>
<div class='slide'>
<h1>Proposal</h1>
</div>
<div class='slide'>
<h1>Process Improvements Package</h1>
<ol>
<li><strong>Updating the Patent Policy</strong>
<li><strong>Streamlining Candidate Recommendation updates</strong>
<ol type='a'>
<li>Allow easy CR "Drafts" between rigorous CR snapshots
<li>Automate routine Director’s approvals
</ol>
<li><strong>Streamlining Recommendation updates</strong>
<ol type='a'>
<li>Add amendment process for bug fixes
<li>Allow adding features to designated Recommendations
</ol>
<li><del>Dedicated Registry Process</del> <i>Rescheduled for 2021!</i>
</ol>
</div>
<div class='slide'>
<h1>Proposed Fix: Patent Policy Improvements</h1>
<div class="note">
<p><strong>Problem:</strong> Patents licenses are only granted after REC, but implementations needed before REC.
<br><strong>Goal:</strong> Secure patent commitments earlier, without depending on meeting REC requirements.
<p><strong>Currently:</strong> We secure promises to license at each exclusion opportunity, but only licenses at REC.
<p style='margin-bottom: 0'><strong>Proposal:</strong> Secure licensing, rather than just commitments to license:
<ul style='margin-top: 0'>
<li>on <strong>full specification</strong>, by all WG participants, at the end of each exclusion period from CR onwards
<li><del>on each <strong>contribution</strong>, by the contributor, at the time of contribution</del>
</ul>
<p>See <a href=''>separate presentation on the Patent Policy (link TBD)</a>
</div>
</div>
<div class='slide'>
<h1>Proposed Fix: Streamlining Routine CR Republication Approvals</h1>
<p><strong>Problem:</strong> Republishing WDs is automatic given WG approval, but republishing CR requires Director’s Approval. Most republication requests, however, are routine and don’t need much scrutiny.
<p style='margin-bottom: 0'><strong>Proposal:</strong> Allow automatic Director’s Approval for straightforward cases, e.g.
<ul style='margin-top: 0'>
<li>Documented WG decision to publish
<li>All changes documented
<li>Horizontal Review groups have approved or waived their review
<li>Resolution of each issue was satisfactory to commenter(s)
<li>No formal objections
</ul>
</div>
<div class='slide'>
<h1>Proposed Fix: Allow CR Drafts between CR Snapshots</h1>
<div class="note">
<p><strong>Currently:</strong> Updating a CR requires external verification of work and triggers a patent exclusion period. Accommodating these reviews slows updates. (Even if we speed up Director’s approvals, legal teams want infrequent patent reviews.)
<p><strong>Problem:</strong> CR publications lag, often significantly, behind WG’s current-work, reducing value and authority of W3C’s official publications.
<p><strong>Goal:</strong> Address use case of Living Standards: always up-to-date, periodic patent commitment</p>
<p style='margin-bottom: 0'><strong>Proposal:</strong> Allow CR draft publications between CR review snapshot publications:
<ul style='margin-top: 0'>
<li><strong>CR Snapshot publication</strong> requires wide review, Director's approval, triggers patent review
<li><strong>CR Draft pubication</strong> can be published by the WG without approval, no patent review
<ul style='margin-top: 0; font-size: small'>
<li>Significant changes since last snapshot must be tracked to facilitate review
<li>Spec header adds links to previous Patent Review publication as well as previous [generic] publication.
</ul>
</ul>
</div>
</div>
<div class='slide'>
<h1>Proposed Fix: Modifying a Recommendation</h1>
<div class="note">
<p style='margin-bottom: 0'><strong>Problem:</strong> Fixing errors in REC requires returning entire spec to CR, re-doing Process from there.
<ul style='margin-top: 0'>
<li>Confuses users (because the spec “loses” REC status).
<li>Excessive process & publication work for WGs and Staff.
<li>Results in poorly-maintained RECs.
</ul>
<p><strong>Goal:</strong> Make it easy to propose, review, and incorporate individual changes without destabilizing the entire REC.
<p style='margin-bottom: 0'><strong>Proposal:</strong> Create an errata proposal + approval process:
<ul style='margin-top: 0'>
<li><strong>Inline Errata -</strong> Allow WGs to republish annotated RECs, noting <strong>proposed changes</strong>.
<li><strong>Review of Proposed Changes -</strong> Combine transition-like checks for wide review, adequate implementation, plus AC and patent reviews on proposed REC with selected changes.
<li><strong>Updated REC -</strong> Reviewed changes can then be folded directly into an updated REC.
</ul>
</div>
</div>
<div class='slide'>
<h1>Proposed Fix: Allow Adding Features to a REC</h1>
<div class="note">
<ul>
<li>Some communities need a specification to represent a stable feature set.
<li><strong>Problem:</strong> Some communities need a specification to represent continuous development.
</ul>
<p><strong>Currently:</strong> REC specifications cannot accept new features; a new level of the technology must be specified starting with a new FPWD.
<p><strong>Proposal:</strong> Re-use REC maintenance process for incorporating <strong>proposed changes</strong> (above) to also allow incorporating <strong>proposed additions</strong>.
<p class='note'><strong>Note:</strong> Only allowed if stated in the specification prior to first publication as REC.
</div>
</div>
<div class='slide'>
<h1>Process Improvements Package Summary</h1>
<ol>
<li><strong>Updating the Patent Policy</strong>
<li><strong>Streamlining Candidate Recommendation updates</strong>
<ol type='a'>
<li>Allow easy CR "Drafts" between rigorous CR snapshots
<li>Automate routine Director’s approvals
</ol>
<li><strong>Streamlining Recommendation updates</strong>
<ol type='a'>
<li>Add amendment process for bug fixes
<li>Allow adding features to designated Recommendations
</ol>
</ol>
</div>
<div class='slide'>
<h1>Impact</h1>
</div>
<div class='slide'>
<h1>Impact on Working Groups</h1>
<ol>
<li>Allow easier maintenance paths for its Recommendations (changes and additions)
<li>Allow keeping CR publications in sync with latest edits, without waiting on Director approval
<li>Secure Patent Commitments earlier than REC:<br>
Full specification commitments at the end of each exclusion period, starting at CR
</ol>
</div>
<div class='slide'>
<h1>Impact on Legal Teams & Advisory Committee</h1>
<ol>
<li>AC/Patent reviews would be more frequent but with finer granularity
<ul>
<li>Formal patent / AC reviews rate-limited to approximately once per six months
</ul>
<li>Full specification commitments earlier than REC, at CR
</ol>
</div>
<div class='slide'>
<h1>Impact on Horizontal Review</h1>
<ol>
<li>HR groups are already under a heavy workload
<ul>
<li>Increasing frequency of review is good, but context-switching is costly.
<li>Improving tooling for more granular feature review is essential to success</li>
</ul>
<li>Proposed fix continues to require demonstration of review at transitions/updates
<ul>
<li>Tied to CR Review Drafts and REC Call for Reviews (rate-limited already for legal).
<li>Patent commitments may stall if review is slow, or if WG has failed to coordinate with HR.
</ul>
</ol>
</div>
<div class='slide'>
<h1>Impact on Implementers and Users</h1>
<ol>
<li>Early implementations get W3C RF commitments
<li>Official specifications (on <a href='https://www.w3.org/TR/'>w3.org</a>) reflect latest WG thinking.
<li>Improved maintenance brings W3C Recommendations closer to reality.
<li>Granular reviews of proposed changes to Recommendations.
</ol>
</div>