Re: WHATWG/W3C collaboration proposal

We seem to be using terms in different ways.  I'm not sure how to 
proceed in the face of that.

I believe that individuals and groups can have influence, and such 
influence can happen before "CR".  I believe I've demonstrated that with 
the URL spec.

I believe that individuals and groups can edit a single document.

On the other hand, I'm having difficulty understanding how an individual 
in isolation can apply the W3C process.  I guess it is theoretically 
possible, but things like the IP commitments would be of less value.

I'll close by stating what I would like to see: I'd like to see 
documents produced with a list of several, and perhaps even dozens of 
editors.  Not segregated as we currently do, with editors defined as 
WHATWG or W3C, but a combined list.  And I'd like those documents to be 
seen as stable, widely implemented, all known issues publicly addressed, 
and meeting the W3C Patent Policy.

- Sam Ruby

On 11/21/2014 06:16 PM, Wayne Carr wrote:
>
> 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 Saturday, 22 November 2014 13:02:20 UTC