Re: WICG Incubation vs CSSWG Process

On 12/23/2016 10:19 PM, Michael Champion wrote:
>> The CSSWG can pick up anything that is in scope for the charter and is
>> presented for its adoption (and is not patent-encumbered), regardless
>> of the source
>
> How does the CSS WG determine whether something is patent encumbered?
> One strength of incubating in WICG or any CG that all contributions are
> made under a Contributor License Agreement that offers a perpetual
>royalty-free license to any patents necessary to implement the proposal.
>  As best I understand, work that incubates in CSS or any other WG doesn’t
>get any kind of patent protection until a promise to make RF commitments
>is implicitly offered once the exclusion period on the First Public
>Working Draft expires, and those promises don’t become concrete until a
>spec gets to Recommendation.  I suspect this is more of a cultural norm
>in the CSS WG – don’t contribute anything you’re not prepared to make a
> patent commitment on at some point – than anything legally binding. Do I
> have this about right?

You're right that this is "enforced" mostly as a cultural norm,
whereas CGs have something more up-front. But that's a legal
side-effect of how the W3C has set things up, and not, imho, a
a fundamental consideration of process. If it's an issue, W3C
should address it for all WGs, as it's not specific to CSS.

Also, IIRC the CG participants make patent commitments for
themselves individually, so patents owned by their organization
(which is most of the ones you're concerned about, I imagine)
wouldn't be covered through the CG process anyway.

>> The MAY appears to give special consideration to work prepared in the
>> WICG, and can be read (and has been read) as being a substitute for
>>  review and development within the context of the CSSWG.
>
> Thanks for that explanation of something that seemed like a very
>minor point to me until this thread clarified it.  As an advocate
>of incubation in WICG or other CGS, I had thought of incubation as
>  NECESSARY condition for going on the Rec Track – solid proposal
>with buy in from implementers and users – and not a SUFFICIENT
>condition.

The CSSWG performs "incubation" as you define it--creating a "solid
proposal with buy in from implementers and users"--as the pre-FPWD
and WD stages of the W3C REC track process. [1] I fail to understand
why incubation in the WICG or some other CG is, or should be, required.

[1] http://fantasai.inkedblade.net/weblog/2011/inside-csswg/process

> It’s apparently not clear enough that WGs make the decision
> to accept the output of WICG, not the WICG itself. In practice,
>they will usually be the same people, but in case they are not,
>there should be no doubt that WICG incubation is not shortcut
> around the WP or CSS WG’s review process.

In practice, the people working on something in the WICG (or in any
other limited-audience "incubation" group) are a subset of the people
who would pay attention to it once it's transitioned to the CSSWG.

As for "shortcutting review"...

Incubation, from what I understand, is designed for in-depth expertise.
But the CSSWG process provides breadth expertise, and issues around
varying implementation architectures, consistency and integration with
the rest of CSS, and embodying CSS's principles of good design are more
likely to show up there. In my experience with spec proposals--even
well-"incubated" ones from the editors' perspective--is that in some
cases only minor details remain to be worked out, but in others
submitting to CSSWG is just the beginning of the design process,
triggering a complete rewrite of the spec as some of these broader
issues are brought to light through the discussions there.

The WICG process, as currently set up with a fixed "transition" point
rather than providing for joint work over time, does not support this
kind of more complex interaction.

Furthermore, many WICG people seem to think the spec should be "done",
aside from minor details, when they're done with it, and the WGs shouldn't
be involved in any actual spec development work. Supposedly all the right
experts are involved in the incubation group. But the truth is many of
these people (like myself and dbaron) are overwhelmed and don't have the
time to be involved in every WICG group ever. These WICG advocates' model
effectively means the WG's broader expertise is never incorporated--because
by the time it's brought to bear it's too late to make any changes. [2]

The CSSWG process is designed to surface higher-level discussions to all
of the CSSWG experts throughout the spec development process. [3] This
helps to keep the experts in any one part of the technology appraised of
and involved in what's happening in the others, so they can see and
maintain the interactions and patterns that keep this complex system
coherent and self-consistent. It brings in and incorporates the diverse
perspectives and problem-solving expertise of the various members of
the CSSWG into the technological decision-making of areas that are not
currently their priority. And it helps members learn about how the we
solve technical problems, resolve conflicts, and maintain important
design principles such as usability, flexibility, and robustness [4]
in addition to the more obvious ones of performance and power. It also,
as a side-effect, helps to ensure that input is properly addressed and
decisions are made with sufficient clarity. [5] So while there's
definitely room for improvement in the CSSWG process as we struggle
with scaling up, and formalizing some aspects of incubation tooling and
practices will undoubtedly help, some of the "inefficiencies" the WICG
and its advocates are trying to eliminate provide useful, if subtle
and under-appreciated, opportunities for improving the technology and
maintaining its development community. They provide opportunities for
learning and for contextual analysis, and provide an infrastructure for
maintaining the coherence and quality of CSS.

What I'm trying to say is, the CSSWG's value isn't in the mere acceptance
or rejection of a proposal and ability to push consequent paperwork around.
The idea that its review involvement should be sought only at the end of
the process as some sort of bureaucratic step (like the AC review)--or even
as a "hammer out the details step"--is harmful.

Conversely, the advantages cited for the incubation process don't disappear
once the work is transitioned to the CSSWG, and the expectation that an
incubation group be disbanded or simply mainlined into the CSSWG also
seems suboptimal. These two things should exist in parallel, the focused
group and the broader one, and together shepherd the technology along its
development track. The fact that the WICG/CG process does not support or
facilitate this kind of joint work makes me flatly opposed to its
requirement.

[2] Implementing and shipping a feature inherently restricts the CSSWG's
ability to make changes or to reject a proposal: once it has embedded
itself in the Web, a technological proposal cannot be rescinded. (Even
once an implementer has an implementation that hasn't shipped, they are
often loathe to change it.) If part of the WICG process is to implement
and/or ship a proposal, that automatically shortcuts the CSSWG's subsequent
discretion. So if the CSSWG's involvement is solicited only at the end of
such a process, then it is effectively not solicited at all. (The CSSWG
has been dealing with the fallout of this kind of "incubation"--see, e.g.
Transforms, Animations, and Transitions--for awhile now; I'm not really
interested in encoding the process of ship-first-review-later as the new
"best practices of Web standardization".)

[3] http://fantasai.inkedblade.net/weblog/2011/inside-csswg/decisions

[4] http://fantasai.inkedblade.net/weblog/2012/css-layout-evolution/#principles

[5] I can't tell you how many times the process of preparing a disposition
     of comments, or of preparing an issue for discussion in the broader WG,
     has brought clarity and thoroughness to my handling of an issue;
     nevermind the at-times critical input of some member of the WG who does
     not ordinarily follow that spec's ML discussions.

~fantasai

Received on Sunday, 25 December 2016 03:37:41 UTC