Charter Review

Christian: We have consensus on our comment. Need input from the wider group on the comment - it may be contraversial.

Marcos: It also has to go out today (the 12th, US East Coast time)

Lola: Still need additional review?

Christian: We had a good discussion and we feel the comment is balanced. Will post it right after this meeting.

JY: I'm worried about the length of the comment, and the assumption that Chromium-only APIs shouldn't be in a WG.

MC: Let's split that into parts. There's vibration and battery status which are chrome only now but were in all browsers, or that was the intention. But some browsers decided to remove tjem. The chrome-only ones fall into the discussion around generic sensors. There's a question of whether use case fort those is valid. The proximity API doesn't list any use cases. So I don't think it's about that it's Chrome only, it just happens that they are. It's more around the architectural models are using the generic sensor. Do these APIs have activity. Going back to the start, the motivation was that devices have these sensors, there's APIs to access them, so let's access them; rather than, is this a good idea or not.

JY: Sounds like a.request to write expaliners for each API, if can't write a good one then drop the API.

MC: Could be an explainer or anything that explains the use case, but needs to make a strong case as to why you might have it. So hopefully that covers at least the chrome-only part, which isn't that relevant. If they're a great idea then they shoujld be starndardized. But larger question is, given the arch. was rejected, their utility is in question -- that's the interesting architectural quesiton.

JY: Makes sense to ask them to describe use cases for all APIIs.

MC: Yeah, or at least revisit them.

JY: Just that would be short comment.

XH: I'm wondering how they would anwser use case question.

JY: I thikn it''d be the user-serving purpose of the API.

MC: The web plat is its own thing -- considering is it available to native apps is not an interesting argument.

XH: But they want to replkicate native app.

JY: My argument is I don't want their to be a reason to write a native app

MC: That's the correct framing. Comes back to, what is not achievable by the web plat today. What problem is this solving for users.

JY: THinking about whether this is good charter feedback, or good spec feedback.

MC: I think it's a charter question. This group is tasked to do stuff, they've done stuff over the yeras, based on particular premise abut how we're doing APIs 10-15 yrs ago. It's been rechartered, but completely fair to say in this modern world, is this stuff still relevant? Wake lock API is an example. There's nothing new being proposed from this group, but if they do, should be looking at it in this way. There's also this old stuff: asking, is it worth pursuiong those, put them on recommendation track, which is the larger question. To me that's a charter concern.

JY: Question of do you have use cases for all the specs, and how do you balance specs that allow some abuse but have use case -- good to include in a charter. One other point about which statuses they should develop specs under. Process forbids moving some of these to note track; can't be done after it's patent draft.

MC: In those cases would be nice if there was signaling even in title to say it's a maintenance thing.

JY: I would want to see examples in other specs we could ask a WG to copy.

MC: Yeah, maybe in payments WG we violated, took the ??? event and moved it out. This is why it's dangerous -- group very quickly moving things into CR, because it creates bad situation where something is in the rec track and we can't move it out.

JY: That's one of the questions I'd like to get a formal rejection council to talk about. What are the formal requirements to get something into CR. Not really a chartering question yet; could get a formal objection and ask council to review it, but not something I want in a charter review before that point.

MC: Can they drop to working draft?

JY: Yes. But if has ever been patent draft, can't switch tracks, go to note.

BK: Could go to deprecated.

JY: Eventually the ones that are duplicated by consensus spec shouldl eventually go to discontinued/superceded.

MC: That's the real solution here depending on what they want to do. They have these specs with features that may or may not be interesting...if there are cool features, should bring those over to other specs. Hopefully that's conveyed in the comment.

JY: At least for the things that overlap, should be building on consensus spec.

MC: That's the bit I'm unsure of, don't know if there's anything interesting in the other specs.

JY: Marcos can you write concise omment or should I?

MC: If you write I'll focus on making more consise..

BK: We do have group of other things we've been talking about being new charter that would cover webviews, maybe miniapps, IWAs. I can see them being different in some of these areas. Curious about if we ask this question about: based on never getting Apple and Moz to sign on to it, but maybe that's just in the browser itself. Maybe a world where they could be standardized but not in the way we have now. Does that modify this feedback in any way.

JY: I think this might be something where Marcos and I disagree. I think we should be able to get things to rec even if only in chromium. Device APIs don't touch engine much, if they have multiple implementations at OS side and UI side, should be ablet o get to rec.

MC: Don't necessarily disagree -- only on the assumptions on which the APIs are built. We evaluated other things on the same basis. Embedded in Brian's question is about other platforms having these capabilities, we want the same capabilities where possible across all UAs. Don't want different permission/feature model, want cohesive architecture. But there are APIs only exposed in certain contexts, like Badging API, only makes sense in WebApp. MiniApps may fall into this category. Or Push notifications only available in installed WebApps.

• Can we categorize the issues into buckets?
  1. The charter needs particular text before going to AC review.
  2. The WG and Team need to make a deliberate decision before going to AC review.
  3. The TAG is merely interested in the outcome.
• One significant issue is the extent to which a browser-focused WG can adopt documents that only 1 browser engine seems likely to implement. Can we find any TAG consensus or near-consensus on this topic?

Jeffrey: We're trying to figure out what has TAG consensus, what needs to change, and what we need WG actions on. Marcos has identified the issues we need to discuss in issue 1187.

Marcos: We have consensus on what the concerns are; we don't have consensus on how to solve them. As a start for https://github.com/w3c/charter-drafts/issues/780, read for the proposal. What might be a suitable action in response to the concerns that the use of the wiki and the verifier result is insufficient?

Jeffrey: pointing back to the actual TAG comment, there's not necessarily consensus that these implementations need to support these in these particular ways, but we are more concerned about what support the group will supply to the spec and where it's headed. For the TAG: do we want just these categories, or do we want the spec to say these engines support these in the following ways? I want to hear from the WG what you're thinking about how to signal your spec's support levels. I want to hear from the TAG as to what direction you want the WG to go.

Anssi: What was the key problem the TAG wanted to solve here?

Christian: Developers could confuse the docs there with formal standards. They might not be happy with current implementation support and draw the wrong conclusions. If the spec authors could clarify that, perhaps by displaying the status more prominantly, that might help.

Anssi: Does the TAG have this type of boilerplate that you generalize across all WGs, or is this WG being treated differently?

Jeffrey: It is a problem that has shown up in a few places. The importance seems to have been higher for this WG. Once we figure it out, we need it shared across WGs and become part of the charter template, once we figure out what should be there. We are asking for the WG's help to figure out what the change to the template needs to be.

Anssi: I would prefer to see a general boilerplate for the charter template that I will see applied across all WG. What was proposed to be added to the text creates more confusion. There is a PR for the charter that is a good solution at this stage when we don't have general boilerplate.

Jeffrey: The charter text doesn't address the problem that people reading the spec don't know where the spec is going. People don't click over to the charter when they are reading the spec, so something in the spec seems useful. We should put it in the status of the doc via respec or bikeshed eventually, but we need to try it out first. The TAG needs to figure out what to ask you for, too. Using Marcos' suggestion of specifying the engine and their position gives too much weight to the browser engines. The categories listed in the charter content are more general.

Anssi: You are familiar with the MDN data project - it documents support across features. I expect our tools would use that data as a source.

Marcos: My feeling from what Christian said, a developer might ask why something has not been implemented. It might be nice to have answers to that, which is why I included the standards positions (which MDN cannot answer). If we have standards positions that are clear, these are ultimately web APIs that are supposed to be implemented in browser engines.

Anssi: I think that's an interesting proposal. Would like to lean on François on this. Marcos feels that it is important to have in the spec direct link to standards position. But the spec is fixed and the positions may change over time. Is that ok if that's dynamically fetched? But if the specs are static until the next commit arrives, that might be a problem.

François: I don't have an answer for WG deliverables. Dom and I are working on an update to community grou preports for the same reasons, trying to make clear that these are CG reports, drafts not supported by anyone, and provide more useful info. Part of that info would be in the front matter and would include links to standards positions. But that's easier for CG drafts because they get updated and have no official standing. For a WG deliverable, it will be harder to come up with the right rules, which standard position to link to, and how to present things. We need to get some experience with the CG before we can apply further to the WG.

Marcos: The challenge with the specs to become standards is that they need to have multiple implementations to exit CR. The underlying intent to having these non-normative boxes is to signal that these are not expected to progress on the REC track due to the positions of the potential implementers. Anssi is right, those positions can change, but we are aware of when that happens and can update the docs when ready.

Jeffrey: This might bring us to the web architectural question. This WG has been operating to push the boundaries of what's possible on the web. It has been doing that when one engine is willing to push boundaries and the other engines thought that was a bad idea. We have the ethical web principle that the web is multiimplementation/multibrowser, but these are not as multi as we would like. A website might be written to use these APIs but would not work on the user's choice of browser engine. We can either remove the feature from the implementing engine, or get the other engines to implement it. A warning at the top of the spec that it's hopeless to complain sabotages the goal of giving developers a path to complain to the browser engines. Do we hold the web back until the engines are convinced intellectually rather than by developer pressure?

Anssi: I think what you described is the essence between WHATWG and W3C work mode. WHATWG mostly works on infrastructure, so it's probably easier to reach consensus across all browsers. But W3C works differently than that, which is not necessarily a bad thing. Someone needs to be the first mover. We are making a disservice for the web platform if we expect all browser to make the investments at the same time. It would be like saying companies cannot roll out 4G phones until all companies support 4G.

Christian: I also believe that single vendors should be allowed to push forward and that normative text is ok. My personal opinion is that we should add the SotD box, it should not be a scary warning, but some kind of fair hint of the status would be good. Anssi had fair points, so the common ground is adding that box with wording we agree on.

Marcos: I don't think it's so binary. The boundary pushing is good but it presupposes that the architectures being put forward area lso good, and the use cases are being addressed in the appropriate way and are valid. For example, with the generic sensors examples, those didn't catch on and we have alternative ones that serve similar purposes. These aren't things taken wholesale. We shouldn't be scaring people with these boxes, but we should be clear about what's being tried and if we can put a timeframe on that. Maybe the use cases we thought about ten years ago when the work started might not fit anymore.

Brian: I object a little that these are scaring people. We shouldn't think of it that way as much as these are informing people. To the example of 4G, we want people to lead and do early implementations, and we want to let developers know the status. When the status is "we actively oppose 4 G for xyz" that's good to know. I don't think that scares people away from commenting. It might put more scrutiny on the rationale. It gives people a concrete thing to dispute. It should be as clear as possible as to what the status is, and if that includes a particular engine that is actively opposed, we should let people know.

Jeffrey: I hear a suggestion that we have a few categories, and we're focused most on the first two. When there is a spec where, in general, people should use the other spec, people should put that in the document. "If you're thinking of using this spec, you should use that one, this one is just being maintained." Or "This spec is pushing the boundaries; other engines are opposed to it." We need the WG's suggestion on how to put that in.

Anssi: A link to standards positions - I'd like to avoid something that has to be maintained. Will talk to François as to what might be appropriate. I don't want to leave any implementers out, so who should I include?

Jeffrey: If a browser or engine wants to be in this section and says "please include my position here" there's probably some threshold here where some browsers are too small to matter, but if there's a reasoned explanation as to why even the small browsers won't implement, that's useful. I do want to question how mucha problem it will be in the spec. Yes, when it's a REC, it's static, but CRs are still dynamic.

Atsushi: Can we tie this to spec metadata rather than human readable in the SotD? There is no place in the process to talk about the SotD. Most working drafts don't show status like this.

François: In the WebDX CG, we maintain mappings between web features and standards positions. We also have a side project collecting developer signals. We got pushback on adding features to the dev signals project about including negative standards positions; they wanted to avoid that push from developers when they feel the tech is not good. We are reconsidering that in the CG so rules may change. Also, links to standards positions seem good, but maybe we can summarize those positions. We did get pushback on that as well; the positions are phrased very carefully and summarization might change that language. I'm superpositive to add info in the spec, but I'm wary of adding this to the charters until we know how to do that and how acceptible it will be to everyone. That's why I want to start with CG then move on to WG.

Anssi: I'm surprised that developers are reading the specs. The ones I talk to are reading MDN. Why are developers interested in reading W3C specs? My developers don't do that.

Brian: Some developers do that, even if you go to MDN, the spec is linked from there. People give talks or write blogs and link to the specs. That's not how developers learn it or reference it day to day, but they still look at the spec. If it's confusing what the spec is saying, and there aren't good signals, it's confusing for developers. It may also cause unnecessary division in the community.

Anssi: The developers I talk to know where to find positions for browsers. That's why I think this is not a problem. So what really is the audience for this? is it a regulator? This kind of box may discourage people from trying features that are new.

Brian: MDN itself flags things as experimental or risky. This is the other side of your same argument. Its relevant, and it does not scare them away.

Anssi: MDN is where developers go, and we'd just be duplicating info. Does MDN link the standards positions? That's where I think developers should go; implementers will go to the specs.

Jeffrey: People writing the MDN read the spec. So this would be sending a signal to people writing that documentation. It is possible that we can stick the info in the doc metadata that can be automatically read by MDN. But I want to get back to next steps for the charter. Sounds like we don't have a full answer before we send the charter to the AC, but maybe the charter can include having the WG figure this out. Suggested text: "The WG will work to add a description of browsers' positions in the SotD of each specificiation"

Marcos: People do read the specs, and this is not new. I worry that leaving it to the WG means it will not get done, which will prevent the charter from progressing because various members will object.

Anssi: It's up to the members to read and cast their votes.

Jeffrey: I think we should consider as to whether we want our problem. Formal Objections are not always a failure; they allow the council to make a binding position. The TAG needs to figure out if a strong majority feels that we should hold the charter on this or allow it to go ahead with the statement the WG will work on this.

Heather: For myself, this feels like an area with such history and passion, that I'm hesitant to try to dive in. With no prior views, as long as it's still a dynamic document, in CR, not REC, having a note at the top saying "here's what's what", I don't understand why that's contentious. If that's already in MDN, great. If it's in both, great. Some people look in each place. Belt and suspenders to have it in both places. Don't know why it's a problem.

Christian: I personally would like us to find consensus here. I believe it is possible and not too far away.

Brian: Agree with Christian and Heather. I feel like I don't want to block this forever, but I do feel like there are a number of bullets in here that seem reasonable and we can do better. It's worth taking the time to see how much better we can do.

Jeffrey: I will re-open this charter review so it doesn't look finished. Anssi, can you organize a WG discussion on this topic? When that's done, we'll re-add to the TAG agenda and we will see what we think of the WG direction here.

Anssi: What is the schedule for the start of the AC review? We can try to do it asynch if we can't find a good time.

Atsushi: I don't have a strict date right now. Current charter period is extended until end of May. We can think about AC review then.

Jeffrey: Let's figure this out asynch.

Marcos: We are asking the WG if we're proposing text. Christian can take over as lead person to suggest the text.

Anssi: Let's try with Christian.