Re: WICG Incubation vs CSSWG Process

A lot of talk going on right now is around patent issues or licensing
licensing concerns.   I'd like to step back for just a moment and ask a
question:  If we could imagine that that is a non-issue, would there still
be a problem?  It seems to me that their would be and the longer this
conversation goes on and the more twists and turns it takes the more I feel
like there is a lot of talking past and simple lack of agreement on what
some things really even mean.

I'd like to suggest that we're not going to get far in this conversation if
we can't deal with that.  It feels like all of the patent/licensing stuff
deserves its own thread which probably should include all the right people
for that discussion.  I feel like that is a probably at least a bit of a
red herring to the "real" concerns (that's not to suggest in any way that
they are not important but simply to recognize that I'm not a lawyer, I
don't even play one on TV.   What I know from many discussions in related
groups and with W3C folks over the past several years however is that
neither path is actually perfect in this respect, that both have pros and
cons, that both have similar features for joining and that so far I have
seen arguments for both well defended by a number of orgs.  So, again,
those issues aside - do we still have concerns... Can we filter _that_
noise into a separate channel and if so, what's left to talk about?

I'd also like to suggest that it seems to me that a number of things are
getting lost in this discussion by the conversation currently being
dominated by those who have concerns about incubation in WICG.  By this, I
mean that a lot of the presentation of things seems colored by that lens,
and it doesn't seem we're even talking about the same things in some cases.

For example, Florian mentioned at some length a particular set of events at
TPAC as proof of his concerns.  Florian and I see/saw that event very, very
differently. What I saw was natural growing pains while we work to figure
some of these things out and articulate them.  Any change inherently
involves some of this.  What I saw was an org make a policy for their team
and perhaps an overly strict first-read of those from a single individual,
then a follow up which attempted to add missing nuance and clarity.  This
isn't the first time that that class of problem has happened in a WG and it
won't be the last whether there is incubation or not.  Further, given that
we've now had that discussion, I don't foresee quite that level of event
likely to be a recurring problem.  We had similar issues at the beginning
of the Extensible Web - some people initially interpreted this in a very
extreme light: Stop all work on anything high level entirely.  We got past
that without too much difficulty and it seems like we will get past this
too as we increasingly agree to the nuance.

Similarly, Fantasai mentions that the CSSWG does incubation, but by my
definition and compared to how it is setup within WICG it doesn't, in fact,
it cannot currently.  Several people have mentioned that they can barely
keep up with www-style, much less every discussion on WICG and also that
WICG groups will by definition be a limited subset of CSSWG/www-style.  But
these are, in fact, two of the key things that WICG was established to help
with.  That definitely requires someone to bridge the gap and explain so
that we can get common understanding or how can we get anywhere.

These sorts of topics, let me attempt:

It is a definite reality that most actual work in CSSWG does not involve
all of CSSWG.  Meetings and even ML threads typically have very few active
participants on any given topic and that a whole lot of drafts and specs
get abandoned or take up a lot of discussion despite having little actual
hope of ever seeing the light of day as an implemented thing.  It is also a
definite reality that work takes a very long time in this model and that we
have historically shipped a lot that only after a decade or so of brewing
is ultimately fairly criticized by the developers it was intended to serve
for several reasons.  First, they aren't ideal when they arrive, second,
their state in CSSWG and how that works is unclear and not easily
communicated.

"Broad oversight" may be true at some level, but it is also a natural
fallout of supergroups that you create islands.  Many topics, for many
participants are just noise.  It's also a natural aspect of work like this
that you break off into smaller groups to go into the details and then come
back to the group once you've worked a lot of it out.  The CSSWG, for
example, would practically grind to a halt without what is jokingly
referred to as the TF task force - that is - two people who do a *damned
lot* of the actual work, then come back and show/defend their choices to
the limited audience who has the time and interest to review it. That's not
a knock on the people who do that work, I'm extremely grateful for them,
it's just a recognition that this is how work gets done in practice - not
just in CSSWG, everywhere.  The exception to the very limited participation
seems historically to when it comes to something that has to prognosticate
about developers will like or understand: The bikeshed.  Everyone has to
weigh in on the color of the bikeshed, everyone.  Everyone except
developers who can't even afford to know about this conversation, much less
follow it because there is far too much noise and unusual/unfamiliar
barriers to entry.   If you feel like it is very difficult for a Florian to
keep up, how impossible is it for someone who isn't a paid participant from
a browser vendor?

WICG doesn't use a mailing list, they use Discourse.  Discourse lets anyone
join and track individual topics.  There's very little reason for anyone in
the CSSWG to follow every thread/topic - it helps them manage the noise.
For developers, this is killer. Please don't say that www-style uses
[topic] headers to help manage this, it's still overwhelming.  Discourse is
young and comparatively less well known, but we get a lot more/broader
sorts of developer participation on discourse.  Working Group members can
be in their working group _and_ participate in a discourse thread, there's
no problem there - many people, including myself, do that.  We can gain
from this too.

But it's more than just a tech choice for conversation, it's about when the
conversation happens and what sorts of expectations it has.   There's less
need to speculate about developers because the model is one in which they
can more easily be involved at an earlier stage.   It also presents them
with a better idea of reality, it provides a space where we can float
clearly unofficial useful fictions for comment without the impression that
it is somehow very likely to become a standard.  Nothing in incubation
should ship in any browser unless it is behind a flag or through some
metered/shutoff-able mechanism (google has an experiment like this).  These
are, to my mind, the things that WICG is about.  There's no good reason
that I can see that something in incubation cannot be brought to the WG's
attention and discussed.

The goal of WICG is simply to do work 'out front', involve the right
people, eliminate noise, provide discussion that you can point back to and
officially bring it into CSSWG.  Yes, it is quite possible that depending
on the topic that throughout the course of discussion, many CSSWG members
got involved, that most of the problems are solved and that there is very
little to do beyond the process in the actual WG.  Again, this is not so
different from how a number of things happen today.  For other things, that
will not be the case - again, not so different from how it happens today.
Personally, I would like to see more of the former because it seems like a
generally better use of time, but that's just me.

I could hold out a few examples of where this has already happened, and
yes, some were perhaps smoother than others - but again, would you not
expect this of anything new? I would.



-- 
Brian Kardell :: @briankardell