- From: Sam Ruby <rubys@intertwingly.net>
- Date: Mon, 24 Nov 2014 11:32:24 -0500
- To: Anne van Kesteren <annevk@annevk.nl>
- CC: Jeff Jaffe <jeff@w3.org>, Wendy Seltzer <wseltzer@w3.org>, Arthur Barstow <art.barstow@gmail.com>, www-archive <www-archive@w3.org>, Arnaud Le Hors/Cupertino/IBM <lehors@us.ibm.com>, "Michael Champion (MS OPEN TECH)" <Michael.Champion@microsoft.com>
On 11/24/2014 11:05 AM, Anne van Kesteren wrote: > On Mon, Nov 24, 2014 at 4:46 PM, Sam Ruby <rubys@intertwingly.net> wrote: >> On 11/24/2014 10:23 AM, Anne van Kesteren wrote: >>> The condition you're missing is that it would be the same person >>> editing the document. I cannot edit X inside and outside the W3C >>> simultaneously. >> >> That condition was not in your email. Whether or not Jeff led you to >> believe this is in dispute. Either way, I see nothing in the existing >> Membership or Invited Expert agreements that supports this claim. > > "The Invited Expert agrees to refrain from creating derivative works > that include the Invited Expert's contributions when those derivative > works are likely to cause confusion about the status of the W3C work > or create risks of non-interoperability with a W3C Recommendation." > > It's the very same reason we want the W3C to stop copying WHATWG > documents. However, putting legal boundaries in place would have > undesired side effects. > > I could never find something similar in the W3C Member Agreement, but > Jeff and Wendy told me it came down to that. Thank you. While what actually was said appears to be in dispute, I do believe that it is in the W3C's best interest to publicly clarify this situation. >>> Which is one of the now many reasons why the WHATWG >>> follows "Hypothetical" #1, without it really being hypothetical. >> >> I will now ask you for clarification as to what the other reasons are that >> the WHATWG would not be willing to collaborate on the URL Specification. > > I can't spreak for the WHATWG. Personally I dislike the W3C Process, > its licensing practices, its many private activities, its forking > practices, its stale publication process that has caused countless > hours of productivity loss due to developers looking at the wrong > specification, its resistance to change, its management deferral to > surveys, the AC, and task forces when it comes to addressing hard > questions, and having to subscribe to two dozen mailing lists to > follow what is happening. Not sure this is exhaustive, there's other > things to do. Thank you. Without specifying which is which, I will state that I agree with some of these, and will state that others are in direct support for specific needs that others have, needs that you may not share. The "stale" publication process deserves a much longer discussion. Errata is a known issue[1] and actively being worked. Regular releases and making the bleeding edge visible[2] is something than many support. Beyond pre-existing W3C agreements and over reliance on stale publications, I'd like to now ask that you provide additional clarification on any of these points that may impact my proposal[3] on this matter. - Sam Ruby [1] http://lists.w3.org/Archives/Public/public-w3process/2014Nov/0004.html [2] http://lists.w3.org/Archives/Public/public-html-admin/2014Nov/0000.html [3] http://intertwingly.net/blog/2014/11/20/WHATWG-W3C-Collaboration
Received on Monday, 24 November 2014 16:33:36 UTC