Re: WICG Incubation vs CSSWG Process

On Sat, Dec 24, 2016, 10:37 PM fantasai <fantasai.lists@inkedblade.net>
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".)
>

In what ways was Transforms, Animations, and Transitions incubated before
shipping?

It seems we are operating on different definitions of the word incubation,
because that is in not an example of incubation in my mind.

For what it's worth, as a big proponent of incubation, I agree that there
are kinks to work out on what happens to a spec once it transitions to a
working group. Might be messy at first because we don't have the experience
to know what works well yet. I'm confident we can figure out a good set of
best practices over time though.

[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
>
>