W3C home > Mailing lists > Public > public-w3process@w3.org > November 2014

Re: WHATWG/W3C collaboration proposal

From: Sam Ruby <rubys@intertwingly.net>
Date: Fri, 21 Nov 2014 17:03:29 -0500
Message-ID: <546FB6B1.8060604@intertwingly.net>
To: Wayne Carr <wayne.carr@linux.intel.com>, "Michael Champion (MS OPEN TECH)" <Michael.Champion@microsoft.com>, Jeff Jaffe <jeff@w3.org>, Revising W3C Process Community Group <public-w3process@w3.org>
On 11/21/2014 04:03 PM, Wayne Carr wrote:
>
> On 2014-11-21 09:59, Sam Ruby wrote:
>>
>> On 11/21/2014 11:59 AM, Michael Champion (MS OPEN TECH) wrote:
>>>
>>> - Hosting that repo and the discussion forums for a spec in a neutral
>>> venue such as WebPlatform.org to encourage broader participation.
>
> A neutral space for discussions may be a way to get both parties in the
> same forum for work on particular specs.  The issue is what would the
> decision policy be.  There seems to be a fairly fundamental disagreement
> on how decisions should be made.  Unless this presumes editors own the
> spec - if that's it I'm not sure I see why this isn't the equivalent of
> everyone doing it in whatwg and w3c deciding if it wants to bless
> snapshots (which I think is Sam's proposal).

I'll share a third option, something I routinely see happening at the 
Apache Software Foundation: community developed work products, ones with 
hundreds of contributors and dozens of people with commit access. 
That's the direction I would like to see the URL Standard head.

I'd encourage exploring the terms "consensus", "community", 
"contributors", and "committers" in the following page:

http://www.apache.org/foundation/glossary.html

> For what Sam proposed, it looks to me that it gives an W3C influence
> only at Candidate REC and later  (and influense only if WHATWG cares
> about these snapshots). That is so late that many things would be widely
> implemented and difficult to change.  It seems just a way to provide
> feedback to the WHATWG and a decision made late on whether it's OK for
> W3C to create a (snapshot) spec that W3C patent policy applies to.  I
> can see why that may be of some use if the work can't move back into
> W3C, but it seems like giving up on that.  I'd need to look at this more
> carefully, but I'm not sure why we'd join that WG.  If the work is in
> the WHATWG then we could go do it in the WHATWG and make recommendations
> directly there.  So, the WG becomes the equivalent of signing the FSA in
> the WHATWG CG, something people can already choose to do I assume.

In my proposal, I'm only proposing adding an option to what W3C Working 
Groups can do, I'm not removing anything.  In fact, given that the 
consensus seems to be that there is no process change required, all I 
may be doing is making more people aware of what they can already do.

My guess is that where you said "influence" what you really mean is 
"control".  After all, anybody who wishes to contribute can do so.

I'll also state that I've worked in ECMA, IETF, W3C, and now WHATWG (not 
to mention numerous open source efforts and organizations).  I'm just 
one example of the fact that there is a large overlap in people involved 
in various organizations.  It is not "us" vs "them".

Speaking as a member of the ASF Board of Directors: if you see something 
at the ASF you want to control, feel free to fork it.  All you need to 
do is follow the terms of the license.  You are free to remove the parts 
you don't like, and whatever parts you do, share with others, accept or 
limit contributions, and place additional restrictions on the your 
derivative work.  All with our blessing.

I think both the W3C and WHATWG could improve in terms of forking. 
Right now the W3C routinely forks WHATWG specs without specifying a 
clear reason to do so.  And the WHATWG makes specs available under a 
permissive license, and then routinely proceeds to criticize those that 
actually do fork.  Both suck here.

My hope is that by proving that direct references to WHATWG 
specifications is a viable option that forking will only be done when 
there is a clear reason to do so.  I'll go further and say that for 
small, modular, specs, it will rarely be necessary.

> Another alternative (at least for some new specs):
> 1. W3C creates a second Permissive Document License that is roughly the
> W3C Software License (but without text about software that is confusing
> when applied only to specs).  So a license that permits the widest
> possible relicensing to other licenses.
> 2. Let W3C WGs choose that license for all their deliverables (specs and
> other docs) or just for specific ones.  Alternately, a WG could use the
> old Doc License and not allow forks.   Let CGs publish under that
> license if they wanted to.
> 3. Use Github to develop the specs in a WG with a license file
> indicating the new permissive doc license and a contribution file
> defining patent licensing commitments for patent claims essential for
> implementing ones own contributions in the spec they are contributed to
> (from one's employer - unless that's waived because the employer isn't
> relevant)
> 4. Decisions made by Chair based on consensus
> 5. Given the licensing model, if some don't agree with the decision they
> can fork in their own repository.

I'm OK with providing that option to those that wish to use it.

> What that could do is allow the WHATWG or some other group work in W3C
> on a spec.  W3C gets the version they want.  If the WHATWG disagrees
> they fork that part.  And yes, that's a fork, but that's life.  But, for
> most of it, is done together in one place.  That is done with a license
> that makes it so if anyone is unhappy at any point, they can walk and
> work on it elsewhere.

I don't see as likely that those who are comfortable working in the 
WHATWG would feel that the option you spelled out is materially better 
than what they already have.

> This wouldn't have to be for everything.  it could just be for some new
> specs.  It would depend only on the AC/Director approving the WG Charter
> to do it.  For something specifically, done with the WHATWG, they could
> have their own branch in the main repository for things they disagree
> with W3C on.

Again, am I personally an "us" or am I a "them"?  I don't think these 
distinctions are useful.

- Sam Ruby
Received on Friday, 21 November 2014 22:04:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:13 UTC