TAG/MeetCandidates2023/Jeffrey Yasskin

From W3C Wiki

Jeffrey Yasskin - TAG Candidate 2023

These are Jeffrey's answers to the 2023 TAG Candidate Questions.

You can also read Jeffrey Yasskin's nomination statement here.

Quotes from the minutes are not verbatim, and may not accurately reflect the candidate's statements.

What's an interesting question about how the Web’s architecture should evolve that you've come across recently?

Large and small organizations need different things from Web APIs, and if we design APIs for one group, it may be impossible for the other group to adopt the APIs. In particular, APIs that need a lot of configuration might be too hard for small organizations to adopt, and APIs that Just Work™ might not work in a way that a large organization is comfortable with. The small organizations need to be healthy for the Web to be healthy, but they also tend to be less able to adopt new APIs quickly or predictably, so browser developers need an extra push to prioritize them highly. But if that push comes in the form of "you can't ship until the API works for everyone", the API might never ship at all. So what's the right path to incubate and then ship APIs that are good for the Web as a whole?

The TAG is well-placed to notice that an API seems too complex for small organizations to adopt, and it often has enough API design expertise to suggest improvements. It may also be able to revisit APIs a couple years after their initial version ships, and encourage browser developers to try again to make usage easier.

What are the technical trends you notice are happening on the Web, and what implications do you see for the work of the W3C?

See the minutes.

Two trends: First, developers moved to frameworks that made it expensive to download web pages. Custom elements also involve heavy downloads before the page is viewable. https://open-ui.org/ has started working to correct this by building some of the patterns into browsers. We need to keep going in the direction of adding browser features.

Also efforts to bring provable identity to the web, such as verifiable credentials and mobile drivers licenses. Governments are writing laws requiring this, despite the risks to the Web. We need to figure out how to push the ecosystem in good directions. Good news is that the PING and WICG have started trying to figure this out.

What should the TAG's role be in reviewing WG charters?

See the minutes.

Charters are hard to review. They're not always useful in determining what direction the group wants to go: the participants can refuse to do things the charter promised to do. The TAG is probably more useful before charters are written, in identifying work the W3C should try to charter a group to do.

When there's energy going in a certain direction sometimes it is better to push things in some direction than to try to block them later.

Maps are increasingly important, but maps are done in javascript today, making them inaccessible. How do you feel about adding maps to the web platform?

See the minutes.

We should try to add maps to the platform. This is an area that browsers have neglected. But it's not trivial to say "we should add this" and then have it happen. This needs involvement from browsers so that it ships. As Dan Clark said in the meeting, the Open UI CG has done a good job of looking at existing patterns, building a coherent proposal, and convincing browsers to come along. The Maps group should engage with Open UI.

How do you think the appointed TAG seats should be used?

See the minutes.

I'm hoping the Team asks the elected TAG for advice in appointments. I appreciate the work the appointed TAG members have done, but I don't like that the same people have been reappointed rather than using those appointed seats to increase diversity. For example, if Matthew isn't elected, I'm hoping the Team will appoint someone with a11y expertise. Similarly, we need to strive for representation from civil society groups, smaller companies/organizations, and probably other categories that I've forgotten here but the other TAG members will remember. I'm also hoping we'll find appointees who are from under-represented demographic and geographic groups.

Has the TAG been taking the wrong approach in any of its recent activities, and if so, what would you change?

See the minutes.

See [#What_specific_things_did_you_accomplish_in_your_previous_TAG_term.2C_or_plan_to_accomplish_in_your_first_TAG_term.3F below] for my more positive response. Being more critical, in several recent design reviews, the TAG has asked the feature proponents for evidence that the feature has multi-stakeholder (meaning multi-browser-engine) support, and implied that the proponent needs to find that multi-engine support before the TAG will take the feature seriously. While it is important that all features be shipped everywhere, and all of the engines routinely give thoughtful and important feedback, the TAG's job is to integrate that feedback and think about whether the Web should include the proposed feature. If the Web should include a feature, but some of the engines dislike it, the TAG should argue that those engines are mistaken.

What can the TAG and W3C do about the environmental and social impacts of the Web?

From the minutes...

EWP are a great approach to pushing upstream; telling API designers what goals they should pursue. Beyond that we should think about what power the TAG actually has. The TAG mostly creates opinions. I want the TAG to push where it will have the most impact.

How do you see the TAG filling a gap in technical leadership?

See the minutes.

I think we need to be cautious before dramatically changing what the TAG focuses on. We should be thinking about what holes there are in the architecture of the web, and what new work we need in order to fill those. But I want to be careful before we dive into that.

The TAG also gets engaged late in the process, when something is on the verge of shipping or goes through wide review on its way to REC. I think that's too late. Things are mostly decided by then. At the PR stage it's hard to change direction. On the other hand, detailed early design review is drinking from a fire hose. I'd like some sort of triage system: not just yes or no, but notice an early review fits into a pattern of proposals that shares some architectural feature, to address architecturally across features. Apply pressure early in the process vs. evaluating late and saying yes or no at the end.

What is the most important problem the Web Platform faces that the TAG could reasonably address?

Answer here.

What values will you bring to the TAG that other candidates might disagree with?

See the minutes.

We should bring new capabilities to the web. For example, web bluetooth. I think it's important to reduce the total harms users face across all their use, whether or not they're using the web platform. Think about what happens if we do nothing -- if we force people to use native platforms to solve their use cases -- and if it's better or worse than designing a feature for the web. I agree we'll have to take risks to do that. I respect those who disagree w/ that direction but that's a value I'd bring.

What do you see as the role of the TAG in relation to regulators?

See the minutes.

I agree we should pay attention to legal regulation. I'm not an expert in that area, so would want to be advised by people like Mark [Nottingham]. Note that the privacy principles are partially aimed at regulators. We have to think what we can usefully say, as the TAG or in specs, that will help regulation. Also think about how to put hooks in specs which regulators can use. For example, parts of the design for Chrome's Privacy Sandbox effort are meant to help regulators distinguish harmful patterns from benign ones. We haven't done that perfectly, of course, and we should keep thinking about how to do it better in new APIs. How to provide useful hooks for things we can't do technically? At the same time we design technical regulation (https://www.mnot.net/blog/2023/11/01/regulators) to do what we want.

What are examples of W3C work that's not really in scope, and of work elsewhere that could be in W3C's scope?

Answer here.

What specific things did you accomplish in your previous TAG term, or plan to accomplish in your first TAG term?

See the minutes.

I'd like to help TAG work better w/ proposals from Chromium project. The review load is heavy. TAG needs to find ways to give feedback earlier without taking time away from reviews for other groups' proposals.

Some proposals have aspects that are boring; the TAG shouldn't spend time on these. Other aspects apply across several proposals. Identify what's interesting, early, and follow it through the whole process. If we figure out how to improve this, other wide review groups might be able to benefit too.

What is your experience/expertise on browser-based front-end and server-backed or back-end standards?

See the minutes.

Back when ActivityPub was developed I was skeptical, but based on its recent success, I've realized I was wrong. The W3C has a role in server to server activity on the web, but my experience is focused on web browsers. I suspect many candidates are in a similar situation. We'll need to reach out to other experts about server to server protocols. I'll try to keep an open mind and ask for help when reviewing.

What organizational or technical skills will you bring to the TAG?

See the minutes.

Retrieved from "https://www.w3.org/wiki/index.php?title=TAG/MeetCandidates2023/Jeffrey_Yasskin&oldid=116767"