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

Re: WHATWG/W3C collaboration proposal

From: Michael Champion (MS OPEN TECH) <Michael.Champion@microsoft.com>
Date: Fri, 21 Nov 2014 16:59:23 +0000
To: Jeff Jaffe <jeff@w3.org>, Sam Ruby <rubys@intertwingly.net>, "Revising W3C Process Community Group" <public-w3process@w3.org>
Message-ID: <1416589162568.29940@microsoft.com>
> > http://intertwingly.net/blog/2014/11/20/WHATWG-W3C-Collaboration

> Thanks for asking.  I'm just one person in this CG, but my first reading
> agrees that it is not clear that any process change would be required.

That's also my initial read.  I think this is consistent with the letter and spirit of the revised process document:  what's important when finalizing a Recommendation is the extent of consensus, RF patent commitments, and interoperable implementation experience at the end of the process, not the mechanisms of how the spec got written and reviewed.

I like the idea of using the URL spec as a test case, but I wonder if we shouldn't use this opportunity to go further and try out some of Robin Berjon's ideas (if I recall various TPAC conversations correctly):

- having a common GitHub repository for WHATWG and W3C versions of a spec and shipping W3C Recommendations off a "stabilizing" branch

- Hosting that repo and the discussion forums for a spec in a neutral venue such as WebPlatform.org to encourage broader participation.

- Experimenting with modern forum tools such as Discourse to seek to avoid fragmenting the discussion across  emails, IRC chats, GitHub comments, Bugzilla, etc. 

Another thought I'd like to discuss that may or may not be consistent with your thinking, Sam: Could we find a consensus across implementer/developer/user stakeholders  about a sensible division of labor between WHATWG and W3C?  WHATWG folks have undeniable expertise in documenting algorithms by which real-world markup  and URLs can be parsed in an interoperable way. But these documents are not necessarily useful guides to website developers crafting URLs or web pages.  There is room for both a  "how to make a proper URL" spec and a "how to parse a real-world URL" spec.   Maybe the IETF has already done the former and there is no work for W3C to do in that space, but if not it seems like a good job for the W3C WebApps or HTML WG to take on.  Clearly the effort Anne started and you have joined on documenting how to parse URLs needs more work. Many I've talked to would be happy to see it published by WHATWG, if they produced stable (non-snarky) snapshots with credible patent commitments and documented interoperability.  

The more fundamental question is whether the WHATWG folks are interested in *either* doing some extra work to create real reference-able standards under their own brand, or whether they would work under a scheme such as Sam is proposing to collaborate on stabilizing/testing/getting IPR commitments under the W3C umbrella.  One way or the other the larger communities of Web stakeholders need useful and powerful but also stable and interoperable specs they can use with some confidence that no one will come after them for royalties.  A revitalized W3C-WHATWG collaboration could produce all that, or the rest of the world will find some other way to make it happen.
________________________________________
From: Jeff Jaffe <jeff@w3.org>
Sent: Friday, November 21, 2014 7:16 AM
To: Sam Ruby; Revising W3C Process Community Group
Subject: Re: WHATWG/W3C collaboration proposal

On 11/20/2014 2:44 PM, Sam Ruby wrote:
> It is not clear to me that the proposal contained on the following
> page requires any W3C Process changes, but I figured you guys would be
> the ones to ask:
>
> http://intertwingly.net/blog/2014/11/20/WHATWG-W3C-Collaboration

Thanks for asking.  I'm just one person in this CG, but my first reading
agrees that it is not clear that any process change would be required.

>
> - Sam Ruby
>
Received on Friday, 21 November 2014 16:59:53 UTC

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