normative spec changes do not always end up as issues filed with browsers

[johanneswilm]

See remarks of @marcoscaceres here: w3c/input-events#149

Is there anything we can do to improve the browser internal communications?

[marcoscaceres]

Using the template would be amazing. When bugs get filed on browser vendors, they always get triaged, so they should end up in front of the right people. Failing that, it's important to ping folks directly.

You can also use CODEOWNERS file to explicitly request review of pull requests for responsible folks.

For Apple at least, you should be able to directly ping any participants of the working group from Apple (there might be other WebKit folks... as many companies contribute to WebKit)... if that fails, please ping me directly on the W3C Slack and I can follow up.

[johanneswilm]

@marcoscaceres In at least some of the specs we work with, we hardly use PRs at all. Instead, the maintainer raises an issue, we discuss it at a call. And if there is consensus, the maintainer (or someone else) goes ahead and creates a commit directly on the main branch of the repository which includes the agreed upon solution.

At least two Apple people participate in every call.

We should discuss why the information about spec changes that also the Apple people agreed to does not reach the Webkit bug tracker and whether the issue is the same for other browser makers - and what we can do about it.

[marcoscaceres]

And if there is consensus, the maintainer (or someone else) goes ahead and creates a commit directly on the main branch of the repository which includes the agreed upon solution.

Yeah, that's not great from a participation/consensus perspective :( That doesn't give people who are not on the call a change to comment. That's why using the template is important.

At least two Apple people participate in every call.

That's great to hear. At the same time, having bugs filed really helps. Even if you are merging stuff into the main branch, it would be great to have bugs filed so stuff doesn't get lost.

We should discuss why the information about spec changes that also the Apple people agreed to does not reach the Webkit bug tracker and whether the issue is the same for other browser makers - and what we can do about it.

Sometimes there can be misunderstanding or people misremembering things? I'm not sure... but hopefully something like I proposed would help?

[marcoscaceres]

oh! and making sure there is tests obviously really helps! As the tests should solve for the ambiguity that can come from English or spec text.

[johanneswilm]

That's great to hear. At the same time, having bugs filed really helps. Even if you are merging stuff into the main branch, it would be great to have bugs filed so stuff doesn't get lost.

Yes, as I said, the process starts with the filing of an issue. People who are not able to participate in the call can comment on that issue. We take up the issues during the call that are marked with "Agenda+".

Sometimes there can be misunderstanding or people misremembering things? I'm not sure... but hopefully something like I proposed would help?

Your solution sounds like a great idea for groups where there is less verbal communication and/or larger distances between the browser developers working on certain areas and those working on the specs.

But I agree, something does not seem to work right if certain issues are lost in (Apple-internal) communication. We'll discuss it and come up with a solution. Maybe it makes sense to take up at least part of the solution you use in other WGs.

[css-meeting-bot]

The Web Editing Working Group just discussed normative spec changes do not always end up as issues filed with browsers.

The full IRC log of that discussion

<sanketj_> Topic: normative spec changes do not always end up as issues filed with browsers
<smaug> s/smuag/smaug/
<sanketj_> github: https://github.com//issues/463
<sanketj_> johanneswilm: Apple didn't get notified about a change made in spec. Apple was in attendence, but is there any process improvement we can make to better notify?
<sanketj_> ...: Please comment in issue.
<sanketj_> wshieh: Will follow up with Marcos as well.

[sanketj]

If the suggestion is just to file implementation bugs for normative spec changes, and have a PR template to enforce that, then that sounds reasonable to me.

[css-meeting-bot]

The Web Editing Working Group just discussed normative spec changes do not always end up as issues filed with browsers, and agreed to the following:

• RESOLVED: File issues on each repo to add a PR template if appropriate. For specs where it's not clear, ask the Editors. Contents of template include a checkbox for 2 implementers are interested, links to implementation bugs, and checkbox that there has been consensus in WG for the change. Start with a PR on EditContext spec, where all members of the group get a chance to review. Issues on other specs can reference that template.

The full IRC log of that discussion

<dandclark> topic: normative spec changes do not always end up as issues filed with browsers
<dandclark> github: https://github.com//issues/463
<dandclark> johanneswilm: There was a change in input-events we agreed on, but it didn't end up in Apple's bug tracker
<dandclark> ...: To fix this Marcos proposed PR template
<dandclark> ...: Discussion is longer than just what's in this issue
<dandclark> ...: Question is should we have a template, or change how we work on these specs?
<dandclark> sanketj_: Whenever we make normative changes, should we file implementation bug? I think that's reasonable
<dandclark> sanketj_: Could resolve on that.
<dandclark> johanneswilm: For those specifications which are implemented in browsers to a reasonable extend, we add such a template to ensure for each change there are bugs filed.
<dandclark> ...: What we should not do is add this to more experimental specs where it's not clear if they will be implemented. Maybe on the way but not implemented yet.
<dandclark> ...: Or may never be.
<dandclark> sanketj_: That's fair. Do you mean selection API spec specifically?
<dandclark> johanneswilm: As I understand it we should have a distinction. execCommand spec you can't rely on it being implemented.
<dandclark> ...: Many things would need to change for it to reflect actual implementations
<dandclark> ...: We can go spec by spec. For selection API, ryosuke is editor. Communication so far is it's not where there is consensus on every change.
<dandclark> johanneswilm: We should not tie Ryosuke or Simon's hands when it's not clear spec is implemented. When they get to stage where want consensus, two implementations, then we can have template
<dandclark> smaug: Who owns that spec
<dandclark> johanneswilm: Spec says webapps, our charter says we own it. So I assume it is here.
<dandclark> smaug: That one has been implemented in all browsers, so we should be filing bugs. That would have caught this recent issue.
<dandclark> sanketj_: +1 to what Olli is saying
<dandclark> sanketj_: Chromium will be working on that in the near future. Important to get impl bugs filed.
<dandclark> ...: And it will be useful to discuss in this WG
<dandclark> smaug: getComposedRange is broken, needs massive changes
<dandclark> johanneswilm: If that's the state it's at we should have those discussions here.
<dandclark> Wenson: Has there been movement on this spec?
<dandclark> smaug: It was just changed
<dandclark> anne: We'll take it back to Ryosuke
<smaug> https://github.com/w3c/selection-api/issues/170 was a recent change
<dandclark> johanneswilm: Can we agree on the principle of making distinction between specs that are ready that should have template, and potentially others like execCommand that are not there?
<dandclark> ...: Cannot force on all specs that all changes are implementable
<dandclark> anne: Having a whatwg style template is a good idea
<dandclark> ...: Want bugs and tests, potentially more things
<dandclark> sanketj_: Can always file bugs, even if they don't implement the spec
<dandclark> johanneswilm: But say with EditContext, only implemented in Chromium. What does the template include? A link to specific issue for Chromium, then a link to general issue for both Webkit, Gecko saying "implement EditContext"?
<dandclark> sanketj_: Yeah
<dandclark> sanketj_: At some point the other browsers will start implementing
<dandclark> sanketj_: Once one engine ships, it's much harder to make changes
<dandclark> ...: There's higher risk of breaking changes. E.g. with getComposedRanges
<dandclark> ...: if we wait for 2 implementers, might be too late
<dandclark> smaug: So need at least 2 implementers for any change
<dandclark> ...: Would like have no objections also, though I know that's not in charter
<dandclark> johanneswilm: I agree it makese sense for EditContext to have that now, but for several years it was microsoft internal thing
<dandclark> ...: Wanted to start getting more consensus as it started to ship.
<dandclark> ...: But to need that consensus from the start, may not be helpful.
<dandclark> smaug: Have proposal for the new specific case, any changes to the proposal need to get approval. Exactly the model EditContext has now
<dandclark> johanneswilm: Should we say we can add such a template to all repos that are implemented in various browsers? can take them one by one.
<dandclark> sanketj_: At what point do we start filing implementation bugs?
<dandclark> johanneswilm: There's a w3c procedure.
<dandclark> ...: There's incentive to start getting consenus, we all want these things to be implemented everywhere
<dandclark> ...: We can make this more formal with template
<dandclark> smaug: Even more important that impl bugs, is to have template saying these implementers are OK with this.
<dandclark> johanneswilm: And this is at the stage where things are no longer experimental?
<dandclark> smaug: EditContext isn't now
<dandclark> johanneswilm: But we can continue to have ideas that don't end up being real specification or aren't implemented
<dandclark> smaug: Yeah
<dandclark> sanketj_: So when an explainer gets accepted by WG, that's the starting point. Once one implementer has shipped, should start filing impl bugs. One master bug for implementing, and specific bugs for specific bugs on browsers that have implemented.
<dandclark> smaug: Need interest from two implementers, no objections
<dandclark> sanketj_: No objection has been a problem in the past. Can be reasons browser can't implement spec.
<dandclark> johanneswilm: Explainer was filed at very beginning. Another case, the UndoManager proposal explainer. Filed years ago. If they put resources on it, makes no sense for them to need consensus on every little PR.
<dandclark> ...: There are no code examples, need to go much further for it to be something to work with.
<dandclark> ...: The explainer stage is too early
<dandclark> smaug: I would expect explainer to be something you could roughly implement
<dandclark> johanneswilm: Explainers for UndoManager, EditContext were years away from being implementable
<dandclark> johanneswilm: For EditContext there was a big gap between the explainer and a more concrete spec and implementation. All of that first phase, it would have been too complex to have gone through this process every time.
<dandclark> johanneswilm: Can we just go through the specs now and decide? Don't need to make a principled decision about when to add for new proposals.
<dandclark> Wenson: Sounds to me like if there's intent to actually ship, that's the difference
<dandclark> sanketj_: Sounds reasonable
<dandclark> johanneswilm: Should our action be - file an issue with each of our repos to add such a template if appropriate. If not appropriate, maintainer of spec can say so.
<dandclark> sanketj_: What's the content of the template?
<dandclark> sanketj_: Someone tried to add one, is that what we should use?
<dandclark> ...: It was "at least 2 implementers, none object"
<dandclark> johanneswilm: Can't say that, have to follow charter.
<smaug> https://github.com/w3c/clipboard-apis/pull/215 is the one for clipboard
<smaug> Just some random example from WhatWG https://github.com/whatwg/html/pull/7934
<dandclark> Proposed resolution: File issues on each repo to add a PR template if appropriate. For specs where it's not clear, ask the Editors. Contents of template don't include "at least 2 implementers, none object", but do include links to implementation bugs, and checkbox that there has been consensus in WG for the change. Start with a PR on EditContext spec, where all members of the group get a chance to review. Issues on other specs can
<dandclark> reference that template.
<dandclark> Proposed resolution: File issues on each repo to add a PR template if appropriate. For specs where it's not clear, ask the Editors. Contents of template include a checkbox for 2 implementers are interested, links to implementation bugs, and checkbox that there has been consensus in WG for the change. Start with a PR on EditContext spec, where all members of the group get a chance to review. Issues on other specs can reference that
<dandclark> template.
<dandclark> RESOLVED: File issues on each repo to add a PR template if appropriate. For specs where it's not clear, ask the Editors. Contents of template include a checkbox for 2 implementers are interested, links to implementation bugs, and checkbox that there has been consensus in WG for the change. Start with a PR on EditContext spec, where all members of the group get a chance to review. Issues on other specs can reference that template.
<dandclark> Sanket or Dan to add the PR on the EditContext spec.