Re: [w3c/editing] CFC: Move ExecCommand to WICG (#185)

@frivoal, appreciate you taking the time to respond. So counter points for consideration. 

> This claim is not supported by evidence. The Working Group works in public, and accepts comments from the general public. I have seen no evidence in practice that moving a spec to WICG enabled broader participation.

So you are tracking every single repository in the WICG then? :) I kindly ask that you don't conflate your personal experience "no evidence" - just because you didn't see it, it doesn't make it not true. There is plenty of participation in both [discourse](http://discourse.wicg.io/) and in the of repos. 

Now, developers don't magically appear because the spec is a WICG - community needs to be built, natured, and maintained. The point is that it provides more ability for a wider audience to participate in the process - it's why the W3C community created the WICG in the first place: to remove the need for "invited experts" and lower the barrier or entry for folks that want to participate in the standards process.

> and there has not been any PR to this spec that had to be rejected due to being submitted by a non member.

Has there been any? If there has been then that would be in violation of the W3C Process and the IPR Bot would have gotten upset. 

Non-members can't make substantive changes to specifications. 

> existing participants of this WG / TF, and are not all in WICG. 

Sure, but all implementers are (we set it up for that reason). And we are not talking about some arduous painful process: for most, it's literally checking a few boxes  clicking an "I agree" button. 

> but going from a place where everyone is to one where everyone could be does not count as "enabling further input".

Sure, but again, the community needs to be built. I hold that it's much more difficult to build the community here. I'm biased because I chair the WICG - but I've also been part of this WG for ~12 years, so know both pretty well. 

> This is true, but I don't see why this fact counts as an argument for CG over WG. The fact that it does have implementation means it is good to have a place to do maintenance and answer questions from browser engine developers.

This isn't a physical place tho. These are thing that people find by searching. The spec could continue to live in the repository, it's just governed by a different IPR policy. Right now, it has zero IPR policy or protection - it's an unpublished Unofficial draft, and slated to remain so. 

> There's not particular reason that a group capable of answering such requests couldn't be recreated under a CG, but it's here now, why mess with it.

For the reasons the document itself states: it's never going to go to Rec, and it's going to stay as perpetual living standard, and it's not something any browser vendor is particularly interested in developing further (though documenting all the warts for the sake of JS library interoperability is appreciated). As you know, I'm a huge living standards fan, but in the appropriate context - a W3C WG is not the best venue to develop a living standard like this one, because it's useless from an IPR perspective. 


-- 
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/editing/issues/185#issuecomment-438523074