Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
johanneswilm opened this issue Apr 15, 2024 · 7 comments
Labels
Agenda+ Agenda item to be inserted in the Editing TF meeting queue

Comments

@johanneswilm
Copy link
Contributor

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

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

@johanneswilm johanneswilm added the Agenda+ Agenda item to be inserted in the Editing TF meeting queue label Apr 15, 2024
@marcoscaceres
Copy link
Member

marcoscaceres commented Apr 15, 2024

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
Copy link
Contributor Author

@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
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor Author

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.

@johanneswilm johanneswilm transferred this issue from w3c/input-events May 9, 2024
@css-meeting-bot
Copy link
Member

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
Copy link
Member

sanketj commented May 10, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Agenda+ Agenda item to be inserted in the Editing TF meeting queue
Projects
None yet
Development

No branches or pull requests

4 participants