Re: WICG Incubation vs CSSWG Process

25.12.2016, 21:08, "Michael Champion" <Michael.Champion@microsoft.com>:
> 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.

You can either go the CG path, which essentially hopes for voluntary commitments - something that we are aware doesn't work very well in practice, or change the Patent Policy, or actually work hard to move stuff to Rec whatever it's actual condition. Choose your failure mode.

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

There isn't a *requirement* that W3C members get an organisational commitment as far as I know. Since CGs aren't part of W3C process, just something W3C decided to try as an experiment, the mechanism for requiring such a commitment would be for W3C to arbitrarily decide on it. Given that it doesn't put any such obligation on the rest of the world, which it does allow to join CGs, that would seem at the very least grossly unfair.

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

If the proposals are moved to FPWD in the Working Group, then a set of commitments are created that bind all participants of the WG. Given that - especially in CSS - this seems to cover a large set of the relevant technology players, I think that's a spectacularly good outcome already. I would be pleasantly surprised if you can get much more than that. 

If proposals can't get to FPWD, I am not sure why it is worth doing a lot of work to get patent commitments, since it would a priori seem that they are unlikely to go anywhere as standards. A world in which any technology that people thought interesting would be available unencumbered might be a nice world, but it's a long way from here to there and I would be pleasantly surprised if we can bridge that gap effectively.

cheers

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

-- 
Charles McCathie Nevile - standards - Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Monday, 26 December 2016 11:33:53 UTC