-
Notifications
You must be signed in to change notification settings - Fork 31
/
incubation.html
231 lines (221 loc) · 10.9 KB
/
incubation.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
<!DOCTYPE html>
<html>
<head>
<meta charset=utf-8">
<title>Incubation</title>
<link rel="stylesheet" href="/StyleSheets/generic-base-1.css" type="text/css">
<link rel="stylesheet" type="text/css" href="assets/main.css">
<link rel="shortcut icon" href="/Icons/WWW/Literature.gif">
<style type="text/css">
.issue {
outline: solid red;
margin-left: 2em;
margin-right: 4em;
}
.issue::before {
font-weight: bold;
content: "Issue:";
}
.subtopic {
font-weight: bold;
}
.subtopic::after {
content: " - ";
}
button {
padding: 5px;
border-radius: 3px;
}
</style>
</head>
<body>
<div id="header">
<span class="logo"><a href="/"><img src="/Icons/WWW/w3c_home_nb" alt="W3C" height="48"
width="72" /></a></span>
<div class="breadcrumb">
<!-- <a href="/Member/">Member</a> → <a href="/Guide/">The Art of Consensus</a> → -->
<h1>Incubation</h1>
</div>
<p class="baseline">This <strong>Guidebook</strong> is the collected wisdom of the W3C Group Chairs and
other collaborators.</p>
</div>
<div class="toc">
<h4>On This Page → </h4>
<ul>
<!-- <li style="display: none"><a href="#purpose">Purpose</a> • </li>
<li><a href="#proposing">Proposing</a> • </li>
<li><a href="#planning">Planning</a> • </li>
<li><a href="#attendance">Attendance</a> • </li>
<li><a href="#"></a> • </li> -->
</ul>
</div>
<article>
<section>
<h1 id="purpose">Purpose</h1>
<p>Incubation is a way of exploring
some new aspect of the Open Web Platform
when the best way forward is unclear,
when feasibility, compatibility, or developer interest is not yet established,
or when early development would benefit from a wide variety of informed points of view
before Standards-track work commences.
</p>
<p>It enables exploration of novel work,
without overly diffusing the effort of a Working Group
or expending a lot of resources on work that is ultimately abandoned.
</p>
<p>
One possible result of incubation is the <a href="process/cg-transition.html">transfer of work
to a Working Group, for Standards-track development</a>. Work might also be forwarded to another group in liaison with W3C.
Another possible result is the conclusion
that this is a promising area of work, but that a number of prerequisites exist
which should be solved first.
Finally, incubators might conclude that
no Standards-track work should be done in the area.
This is still a valuable result,
as it can reduce the effort expended on unfruitful options.
</p>
</section>
<section>
<h1 id="venues">Venues for incubation</h1>
<p>Incubation can be done in several places;
the correct choice depends very much on such factors as:</p>
<ul>
<li>the specific work area</li>
<li>the existence of already established communities, at W3C or elsewhere</li>
<li>the estimated likelihood of success</li>
<li>developer interest</li>
<li>desirability of early IP protection </li>
</ul>
<section>
<h1 id="wicg">Web Platform Incubator Community Group (<a href="https://www.w3.org/community/wicg/">WICG</a>)</h1>
<p>Established specifically to incubate potential new work
for the Open Web Platform,
this venue has the merit of a large critical mass of knowledgeable developers.
A huge number of proposals pass through WICG.
This has the benefit that it is very easy to suggest a new one,
and the drawback that a particular proposal may easily be overlooked
unless effort is made to socialize the benefits and encourage review and comment.
</p>
<p>Mature proposals are made and tracked on the
<a href="https://github.com/WICG/proposals">WICG Proposals Repo</a>,
while early explorations and less formed ideas should start on
<a href="https://discourse.wicg.io/">Discourse</a>.
</p>
<p><button><a href="https://www.w3.org/community/wicg/join">Join WICG</a></button></p>
</section>
<section>
<h1 id="cg">A Community Group</h1>
<p>Starting a new, topic-specific Community Group
is a little more effort than proposing an idea to WICG
but can have the advantage of review by
a more focused group of people with shared interests
or topic-specific knowledge.
It is a good option when one or more external communities already exist,
but are not necessarily made up of W3C Members.
</p>
<p>There is a <a href="https://www.w3.org/community/groups/">list of existing CGs</a>.
Check whether a suitable one already exists before creating a new one. </p>
<p>An emerging pattern is, when chartering a Working Group,
to use a CG to handle incubation for topics related tothe Working Group.
Regular joint meetings between WG and the associated CG
provide opportunities for progress reports
demonstrations,
and discussions on moving particular items to the WG.
<em>Note:</em> depending on the chartered scope of the WG,
adding a new Standards-track work item may require rechartering the WG.
</p>
<p><button><a href="https://www.w3.org/community/groups/propose_cg/">Propose a new CG</a></button></p>
</section>
<section>
<h1 id="submission">Member Submission</h1>
<p>If work has already been explored by one or more W3C Members,
a Member Submission can be an effective way to bring the work to wider review.
Like other incubation methods, a Submission is not a guarantee that
Standards-track work will take place in the area.
The likelihood of success is increased if there is already developer interest,
and if royalty-free commitments to known patents are made along with the submission.
</p>
<p><button><a href="/policies/process/#Submission">Member Submission Process</a></button></p>
</section>
<section>
<h1 id="workshop">W3C Workshop</h1>
<p>A <a href="meetings/workshops.html">W3C Workshop</a> can be a good way
to bring a new community together and,
if consensus is reached on some new area,
the workshop report may suggest next steps
including creation of a CG, or even
passing the work to a new or existing Working Group.
</p>
</section>
<section>
<h1>A Working Group</h1>
<p>In some cases, incubation
can be done directly in a Working Group.
For best results,
the chartered scope should be broad enough to permit this,
the proposed work should be closely related to existing work items,
and the chairs should ensure that discussion on incubated work
does not interfere with progress on Standards-track items.
For example, a separate call or a separate GitHub repo,
or use of GitHub issues and labels,
can keep the incubation and Standards-track items somewhat separate.
</p>
<p>
If the community of interest is wider than the existing WG,
a tandem CG is probably a better choice.
</p>
</section>
</section>
<section>
<h1 id="review">Getting Review</h1>
<p>
Early review of a new proposal is crucial to success
(whether success means further development,
or early identification of unsuitable areas of work which should be dropped).
</p>
<section>
<h1 id="explainer">Create an Explainer</h1>
<p>
Since the incubated work is by definition novel,
it is important to explain what it is,
what benefits it would bring,
and how it would fit in with the rest of the Open Web Platform.
This is the job of an <a href="https://tag.w3.org/explainers/">explainer</a> document.
A good explainer balances conciseness with detail,
has many examples,
and ideally links to a prototype of the proposed work.
</p>
</section>
<section>
<h1 id="tag">TAG review</h1>
<p>Once some discussion has taken place,
and an explainer exists,
and the proposed work is agreed to be promising,
then before moving the work to a Working Group,
it is good practice to <a href="https://github.com/w3ctag/design-reviews">request review by the Technical Architecture Group (TAG)</a>.
</p>
</section>
</section>
<section>
<h1 id="next-steps">Next Steps</h1>
<p>
If it is concluded that work should <em>not</em> be further developed,
update the explainer to document that fact
and list the reasons that development ceased.
This will help people in the future who may have the same or similar ideas;
perhaps some of the factors (such as developer interest) change in the future.
</p>
<p>TODO </p>
<ul>
<li>IPR commitments</li>
<li>deciding to stop work</li>
<li>liaison with external groups</li>
<li>when to do early horizontal review</li>
<li>prototyping, extensibility points</li>
<li>splitting work into current and future versions</li>
</ul>
</section>
</article>
<hr>
<p>Feedback is to <a href="https://github.com/orgs/w3c/teams/guidebook">@w3c/guidebook</a>
and is welcome on <a href="https://github.com/w3c/Guide/issues">GitHub</a></p>