Re: WICG Incubation vs CSSWG Process

Fantasai,

Well stated.  Thank you.

Jeff


On 12/24/2016 10:37 PM, fantasai wrote:
> 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 04:54:17 UTC