Re: [w3c/charter-html] Charter must state a reason when duplicating work done elsewhere (#139)

> I'm not sure how "high level" a motivation you want.

The kind of statement @michaelchampion just made probably should be condensed a bit before being put in a charter, but it is a clear stance from which we can derive conclusions about which document should be covered, and what kind of divergence is desirable.

> One possible rationale for the WP WG taking on specs that WHATWG is developing upstream is to get the broad patent commitments that come with W3C Recommendations. Until such a time that WHATWG operates under an IPR policy that generated credible royalty-free patent commitments, this is a defensible reason for duplicating the specs. But I'm not sure folks on the W3C side would agree this is the main value add from the W3C version of HTML, DOM, etc. And I'm pretty sure folks on the WHATWG side don't consider this a sufficient reason for the duplication. But the larger community benefits from the outcome of this inefficient and error-prone system so long as people look to the Living Standards as the up-to-date version and the W3C versions as a guide to what has binding patent commitments.

This is a reasonable stance. If that is our primary goal, I would expect to see only two types of differences between W3C drafts and WHATWG drafts:
* postponing less mature features to later revisions so that the current one can got to REC
* When WHATWG specs differ from actual implementations and WHATWG editors refuse change their spec accordingly, the W3C specs should match implementations rather than the WHATWG spec, since implementations are what need patent protection.
Any other change would seem undesirable, as it takes effort to make despite not being justified by the goal, and can even make the work of determining where the two specification differ harder, probably leading to accidental differences between the two. In this scenario, the fact that most implementors work with the WHATWG document rather than with the w3c document (as I have repeatedly heard from implementors) is mostly a non issue.

Does that make sense to you @michaelchampion ?

With this as a goal, I'd still be a little bit confused as to why we maintain our own copy of specs from WHATWG and not from the IETF, but at least I'd know what to expect about those we do handled.

I'd note that the current modus operandi of the WebPlat WG does not seem to match that, and has a much more independent editorial control that what I suggested above. 

> A co-editor of the HTML spec here. I can only talk to my motivation for working on HTML at W3C. It affords me and interested members of the community more opportunity to provide accessibility related normative and informative content in HTML. Why don't I just contribute at WHATWG? I do, but the priorities and ideological orientations of the editors of the WHATWG spec are different to mine and the community I work with. This sometimes leads to an ossification of incomplete or incorrect information in the WHATWG spec, that I am able to avoid in the W3C spec.

This specific accessibility argument, as well as its generalization (The W3C consensus based process and the community it enables leads to better specifications that take the needs of more stakeholders into account) also seem valid, but I think it leads to different conclusions from the point @michaelchampion made. Under this goal, our editorial independence is a valuable feature, not a bug. The current modus operandi of the WebPlatform WG seems more compatible with this vision.

On the other hand, the fact that the community is at best fragmented, and arguably WHATWG centric is a double problem: not only does it limit the benefits of consensus and broad review, but also it means there is a pretty high chance that implementors may fail to notice substantive improvements and differences present in our specification but not in the WHATWG's, rendering our potentially better work irrelevant.

In this case, identifying and addressing the reasons that cause many implementors to only or primarily work with WHATWG drafts should be a top priority, and the Success Criteria of the WG should probably explicitly call for trying to establish our version of such specs as the primary reference over its alter-ego in the mind of most implementors. Otherwise, regardless of technical merits our spec risk ending up being fiction, and IPR protections that don't match implementations aren't that useful.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/charter-html/issues/139#issuecomment-301686160