Agenda for Aug 31 meeting

[robnyman]

Note: this meeting is in an APAC-friendly time

What we'd like to discuss is:

• The information for public proposals (file view)
• The charter (file view)
• Tip: Philip posted a nice tip for Tip on reviewing markdown on GitHub

This discussion is completely optional, and if you are interested in talking more about these topics, you are more than welcome!

Looking forward to talking more!

[foolip]

These are the issues we need to resolve for the charter:

• [charter] What is a specification as currently defined in the charter #121
• [charter] implementation requirement #122
• [charter] loose-end: case by case #123
• [charter] How to request to join #124

For #115, the main issue is documenting investigation effort proposals, in particular what advice we should give for defining the investigation scope, and how liaising with standards groups should work.

[foolip]

Meeting notes

Present: @foolip @gsnedders @karlcow @robnyman

How to request to join

@karlcow: Point of contact via email, or open issue in repo? Has anyone new requested to join yet?
@foolip: No, we formed the group last year, and haven't had requests to join. Risk of having a totally open process to join is that anyone can join and oppose everything. Not likely, but an unnecessary risk.
@robnyman: For Open Web Docs, we have a Governing Committee and Steering Committee split. The SC can jointly decide to invite more members.
@karlcow: One model is that the team can invite new members, as opposed to others requesting to join.
@foolip: Looking at what we have right now, and we just define how to request to join, would that be OK with everyone? Public or private request?
@karlcow: Private would be better.
@foolip: Do we set up interop@web-platform-tests.org? Who owns the domain again?
@gsnedders That's @jgraham.

Resolution: Define that a request to join is sent to a joint email address. Leaving by request or consensus.

Specification requirements

@foolip: Could it help to differentiate between requirement when proposing and requirement when accepting?
@gsnedders: One case worth mentioning is CSS Containment. At the time of the proposal last time it was Editor's Draft and when the proposal was accepted it was FPWG.
@foolip: What's the crux of the matter, what's most important to Apple?
@karlcow: One issue is the work in https://github.com/web-platform-tests/interop-2022-viewport where there's some things that should happen in the WG.
@foolip: I see, I had thought about the charter language as basically the bar for focus areas.

@foolip: Two main issues I think then is (1) what specifications are acceptable for focus area proposals and (2) are investigation efforts limited in scope to informing WGs about a problem.
@karlcow: Is it the same people doing the work?
@foolip: Yes, at least now the people in the investigation efforts are also WG members. (Didn't check every case.)

Investigation efforts

@foolip: For investigation effort, would it be acceptable to take on goals for resolving a spec issue, within the WG?
@karlcow: If one finds a wrong test, or finds a spec problem, I'd file a WG issue and discuss there.
@foolip: This part I think there's no disagreement on. We can write this down.
@karlcow: How has this worked in the past?
@foolip: We've experimented our way here.
@gsnedders: The people in the interop team are also members of the WGs.

@foolip: Could we have a model where the investigation effort proposal needs to involve more formally liaisoning with the WG, asking their permission?
@karlcow: What happens if a part of a spec gets removed during the year, do the tests get dropped from the dashboard?
@foolip: Yes, this has happened with the CSS color-contrast() function and other bits.
@gsnedders: I would push back a little bit against having to ask the WGs permission. How does a WG give permission for people within the WG to work on things?
@foolip: I think it's the public/metric part that might be a problem.
@gsnedders: Informing the WG that we're intending to do it would be reasonable, but asking permission might be a step too far. If we ask WHATWG HTML about feature X, how does it decide? Refer it to the SG?
@robnyman: Agree, if we use a word like "permission" a decision has to be made. So keep informed, and it's implied that if they have strong concerns we'll take that into consideration.
@karlcow: Was there WG discussion in the past?
@gsnedders: There was when CSS contain was approved.

@karlcow: Sounds like the 4 of us are in agreement. We'll discuss internally at Apple.

Conclusion: When we define an investigation effort, we inform the working group and everyone who works on that effort needs to join the working group to do any spec-related work.

Spec maturity

@foolip: The charter now just lists some SDOs. Minimum change?
@gsnedders: I think the concern is things in incubation, not adopted by any group.
@karlcow: This is about interop, not a way to wedge in work that there's no consensus on. There is a protection against this in that only one objection is required. But there should be a willingness from all browser vendors to work on the technology.
@foolip: Two approaches suggested is defining the bar for a spec or to look at implementer interest.
@karlcow: For things that have no implementation at the beginning of the year, those are different than existing features.

@foolip: In the end, do we change the wording around standards orgs? I'd like something very clear.
@karlcow: Standards track is clearly defined in W3C.

Conclusion: Apple will suggest concrete wording on the charter.

[foolip]

For anyone following links to traverse meetings, this meeting was between #118 and #127.