chaals
commented
5 years ago I would prefer to leave it where it is, although formally I will abstain ...
Closed LJWatson closed 5 years ago
chaals
commented
5 years ago I would prefer to leave it where it is, although formally I will abstain ...
LJWatson
commented
5 years ago @johanneswilm for the avoidance of doubt, could you indicate whether you support the proposal or not? It seems not, but disagreement on a particular point doesn't necessarily mean so.
johanneswilm
commented
5 years ago I disagree with the proposal.
If W3C is getting some type of funding based on ratio of specs reaching recs or similar, I support making changes to draft statuses, etc. if it means that there is no perceivable difference to the JS and browser developers, they can find all the documents in the same place and we only have to consider one email list and one meeting to deal with everything editing-related.
As far as I have come to understand though, this is not the case and it will only make life more difficult for those trying to solve the complex issue of fixing text editing on the web with all the aspects that come with it. JS editors currently have to execute at least two execCommands (on Firefox) and possible 1-2 more in other situations and the rest of the time they deal with other editing related APIs. They don't care in which spec things are - they just need to get it done with at least one of them. Sending them to different meetings to discuss basically the same thing and hope that at least one of the groups comes up with a usable API that is being implemented bugfree for each particular operation they hope to achieve (make bold, enter some text, cut something, enter an image, etc.) is likely to set back the progress we have achieved in this area over the past four years.
I also disagree that "It will enable more input from the developer community" to move it to WICG. If it's burried among 300+ other groups on other things and no longer with the rest of the editing-related documents it will likely mean less input from developers.
You may or may not be aware of me having contacted all JS editing projects we have been able to identify and collect opinions from them on a number of issues as well as invite them to join the mailing list and comment on github.
There is a good chance we will get just as many execCommand-related issues filed in the editing taskforce with the difference that those issues will ask for adding execCommand-related features to the other documents we have there. Already now a fair amount of issues filed there from people who have not attended Editing Taskforce meetings are related to execCommand in some way or other even though they can see that the execCommand spec has a huge note saying that this is not really the way to move forward (in our opinion).
frivoal
commented
5 years ago I've voted against the CfC, but would like to respond to some claims that were made:
Reasons for moving ExecCommand to WICG:
- It will enable more input from the developer community
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.
I am aware that the rules for contributing PRs in CGs and WGs are different, but that has no bearing on the developer community "providing input", and there has not been any PR to this spec that had to be rejected due to being submitted by a non member. Furthermore, all the relevant parties (browsers, js-based editors) are existing participants of this WG / TF, and are not all in WICG. Yes, they could become members of WICG, but going from a place where everyone is to one where everyone could be does not count as "enabling further input".
ExecCommand will ultimately be replaced by contentEditable and Input Events
If by "be replaced", it is meant that these new specs will be the right solution to the same problem, then yes. If by "be replaced", we mean that exec command will be dropped by browsers, then that sounds unlikely. Despite all its bugs and unpleasantness, it's been part of the platform for a while, and is depended on by countless sites.
frivoal
commented
5 years ago The specification has implementations, but not interoperability
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. 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.
marcoscaceres
commented
5 years ago @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 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.
johanneswilm
commented
5 years ago 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.
This probably applies to some working groups, but in this editing taskforce, I doubt that you could build much more of a community than what we have done already. The number of JS editing projects out there is limited. And we have been writing to every single text editing project out there to ask their opinions about various things - and inviting them to participate more directly in some form. There are several that have been participating in physical meetings as well and of course on the mailing list. The reason several of them prefer to wait for me to email them with questions every now and then rather than write on the email list themselves is that likely that they have a business to run and a software to maintain and therefore only participate if they see things moving in the wrong direction. I doubt adding a WICG community page will change any of it. Also the number of text editors out there is somewhat naturally limited by the amount of effort it takes to program one (several years) and the relatively slim profit margins in the sector.
When it comes to developers working on editing code in browsers - we have participation in some form or another of those developers from at least Firefox, Chrome and Safari, and we have representatives from all four browsers participating in the taskforce at all levels.
I don't know who is in charge of the email list and if there should be some kind of strict check for IE in there, but reality is that there is not, nor is there on filing github issues. My own participation started, if I recall correctly, in that I started posting things on the email list and eventually someone from the W3C asked me to please click through something to accept status as an Invited Expert. I don't really see how it could have made sense for me to start changing files on github before talking to anyone on the mailing list.
So far this sounds to me like a solution in search for a problem. I see no benefit to us. But maybe there is some benefit for the working group that statistics look better if some specs are not there? In that case I can understand why it makes sense to do some bureaucratic shuffling around of documents, and in that case I just think it's important that we are not affected by it in any substantial way.
frivoal
commented
5 years ago 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 and in the of repos.
I don't claim that things in WICG don't get participation. Certainly a number of them do. I don't dispute that it is possible to have a vibrant community in WICG. I do dispute that moving to WICG will, in itself, "enable more input from the developer community".
I don't think this has been the main reason behind the proposal to move, but if we're going to claim that a reason to move a spec from some place to WICG is because that will grow the community, then the burden of proof is on those who ask for the change of venue on these grounds.
Has there been any? If there has been then that would be in violation of the W3C Process.
No, there hasn't. That's what I'm saying. So far, as far as I know, we don't know of anyone who wanted to or attempted to propose a normative change, and couldn't due to not being a member. An for any other type of participation, any github repo is as easy to participate to as any other.
Sure, but again, the community needs to be built. I hold that it's much more difficult to build the community here.
Given that the task force already involves all browsers and all major javascript based editors, the difficulty of building the here is irrelevant: it has already been built. (although I still contend that if the ease of building communities is going to be relevant, those asking for a change against the status quo need to back up claims).
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
RIght, the IPR angle is a bit annoying. I think that it is a problem that work artefacts of WGs that don't get to REC (either because they're slow, or notes, or fail before REC, or whatever) have no IPR protection is a problem. I'll try to push at the AB level so that the "immediate patent commitment on your own contributions" IPR regime current found in CGs is extended to pre-REC / non-REC work products of WGs. This might take a while though :)
In the short term, for this spec, it won't make much of a difference either way: the document was produced outside of a CG, and is hardly receiving new contributions. The part of the spec that would be covered by the CG IPR regime would therefore be null or negligible.
marcoscaceres
commented
5 years ago I'll try to push at the AB level so that the "immediate patent commitment on your own contributions" IPR regime current found in CGs is extended to pre-REC / non-REC work products of WGs. This might take a while though :)
Long term, I think that would be great.
So I think the above cover all the positions pretty well. Thanks everyone for the input!
Let's see where the votes fall.
LJWatson
commented
5 years ago @marcoscaceres wrote:
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.>
It is possible to accept a substantive contribution from a non-member. They need to sign a patent agreement pertaining to their contribution (there is a form for this), and the PR can then be approved via Ashnaz.
The process usually involves some discussion (exploration as to why the contributor is not a WG member, content of the PR etc.), but this tends to be fairly painless. Recent examples include Facebook contributing to Service Worker and Salesforce contributing to Web Components, when both specs were in WebPlat and neither organisation was able to join.
It is also possible to make the contributor an Invited Expert (IE). In WebPlat (and WebApps before it) this has been a very simple process. If the person is actively contributing (and a substantive PR is good evidence for that), we tend not to have any problem with including them as an IE to the WG.
marcoscaceres
commented
5 years ago @LJWatson, understood. The WICG by design minimize those points of friction by, in many cases, removing the need to interact with other humans (i.e., it's just a matter of clicking boxes and buttons, no emails, no "oh, can you please make me an invited expert? should we make X and invited expert? etc.").
So, even though the process is "very simple" - in the case of this WG it involves at lot of humans.
johanneswilm
commented
5 years ago It does not happen that often, and when it does, being named an "Invited Expert" of something or other on the internet by real human beings feels more like one takes on a real responsibility, while clicking through some system to create yet another account which other human beings may or may not have noticed gives much less of that.
I don't know if someone has done some sociological research on it, but it would be interesting to hear what motivates people working in small and medium sized companies who in most cases already have invested time in developing around all the bugs and lacking API of browsers and therefore really aren't that affected by it to attend meetings and online discussions to improve the overall infrastructure of the web, thereby potentially inviting others to create similar products in less time. It shouldn't really have to take many years to create a JS text editor, for example. My guess is that the "Invited Expert" title is part of what motivates that.
marcoscaceres
commented
5 years ago We are getting off topic :)
LJWatson
commented
5 years ago With six objections and two votes of support, this CFC does not pass. We will keep ExecCommand on the charter for the WG.
Thank you to everyone who participated.
This is a Call For Consensus (CFC) for the proposal to move the ExecCommand specification to the Web Platform Incubator Community Group (WICG).
This proposal has been discussed in the Editing Task Force (TF).
There are reasons for moving ExecCommand to WICG, and reasons to keep it in the WebApps WG (which is expected to partly replace the WebPlat WG).
Reasons for moving ExecCommand to WICG:
Reasons for keeping ExecCommand in WebApps:
If you think that ExecCommand should move to WICG, please respond to this issue with a "thumbs up".
If you think that ExecCommand should remain in the WG, please respond to this issue with a "thumbs down".
If you do not feel strongly, or do not want to participate in this CFC, please put a "0" or "abstain" in a comment on this issue.
You do not need to respond at all, but it really helps if you do. If you would like to respond privately, you can send your response to team-webplatform@w3.org instead.
Please respond to this CFC no later than the end of your day on Tuesday 20th November 2018.
@marcoscaceres @chaals