Re: WICG Incubation vs CSSWG Process

Jeff wrote:
>    Well stated.  Thank you.

Yes, thanks for the very detailed explanation! 

 A couple of points:

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

Yes, IMHO we should address the lack of patent promises in WGs for work that doesn’t get to FWPD and binding commitments for work that doesn’t get to Recommendation.  That, however, might require revising the Patent Policy, which very few people have much interest in.  It also might be possible to do this via the Process Document, I’m not sure, but it’s worth discussing with attorneys exactly what room to maneuver we have here.

> 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 summary https://www.w3.org/community/about/agreements/summary/  says “The policies encourage organizational licensing commitments (rather than individual licensing commitments) which provides more safety to implementers.” I’m not sure where this is made explicit in the CLA or the W3C policies that require W3C members joining a CG to have their AC rep make an organizational commitment.

That said, this discussion has made it clearer to me why many in the CSS WG are resisting proposals to incubate CSS proposals in WICG.   If incubating the next generation of CSS specs in WICG is a non-starter to participants, I would like to see some discussion about how tweak the W3C to ensure that proposals have some legally binding patent promises – as opposed to a just a cultural norm – at least from those making them.  There might be a way to do this within the current W3C process and patent policy, or it might be something we can address in the next revision of the process.   

Likewise it would be good to figure out how the W3C WG process or the CSS culture could be tweaked to ensure that the w3.org/TR page doesn’t remain littered with supposed Rec-track specs that aren’t going anywhere because proponents lost interest, don’t solve a real world problem, or nobody plans to implement them.  That’s one of the problems WICG was intended to solve, by not putting specs on the Rec track until they had sustained interest, demonstrably solved a real problem, and had implementer buy in.  There’s surely other ways to solve that problem besides insisting on incubation in WICG, so let’s discuss.


-----Original Message-----
From: "jeff@w3.org" <jeff@w3.org>
Date: Saturday, December 24, 2016 at 8:54 PM
To: fantasai <fantasai.lists@inkedblade.net>, Michael Champion <Michael.Champion@microsoft.com>, "public-w3process@w3.org" <public-w3process@w3.org>
Subject: 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 20:08:23 UTC