- From: Sam Ruby <rubys@intertwingly.net>
- Date: Sat, 22 Nov 2014 08:01:51 -0500
- To: Wayne Carr <wayne.carr@linux.intel.com>
- CC: Revising W3C Process Community Group <public-w3process@w3.org>
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