Open johanneswilm opened 4 months ago
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.
@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.
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?
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.
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.
The Web Editing Working Group just discussed normative spec changes do not always end up as issues filed with browsers
.
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.
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.
See remarks of @marcoscaceres here: https://github.com/w3c/input-events/pull/149
Is there anything we can do to improve the browser internal communications?