Re: WHATWG/W3C collaboration proposal

On 2014-11-21 14:03, Sam Ruby wrote:
> 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.

that's a postive thing the github approach folks are already working on 
makes simpler

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

No, I meant "influence".  I don't think your proposal gives W3C any 
control over WHATWG.   If WHATWG cared, that would provide the ability 
to influence (I doubt they'd care enough to call that control).  My 
point was it was too late in development.
>
> 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.

  One benefit is that the work on a spec that used this would all be 
under a license that allow derivatives, so a WHATWG version could use 
content from the W3C version, not just the other direction. That means 
they can work on it jointly with W3C and still maintain their own 
version since they have access to all the text under a permissive 
license.  So they don't have to work only in WHATWG.  It provides the 
possibility to all work together.  I would hope that over time more 
could be done together because people knew they always had the option to 
split if it didn't work.

That doesn't happen under the proposal where all the work is in the 
WHATWG and W3C just decides to publish snapshots or not.  So, I think 
this alternative provides more flexibility for working together, rather 
than formalizing that the work be done outside W3C.

>
>> 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.
I find that very puzzling.  Your subject line is "WHATWG/W3C 
collaboration proposal".   Your proposal is full of what W3C would do or 
what the WHATWG would do.  What distinction do you think I'm making that 
isn't useful?

>
> - Sam Ruby
>
>
>

Received on Friday, 21 November 2014 23:17:25 UTC