Meet the 2024 TAG Candidates: Daniel

What is the most important problem the Web Platform faces that the TAG could reasonably address, and how will you start to address it if you're elected?

The TAG's most important duty is to help the web advance by reviewing matters relating to web platform architecture. When done well this technical stewardship helps the web progress in a way that ensures cohesiveness between different emerging technologies, and ensures that horizontal concerns issues like a11y, security, and internationalization are not regressed by emerging standards. Performing this duty promptly and objectively will ensure that the TAG remains maximally relevant and helpful to people working on standards as well as the developers and users impacted by these changes.

The TAG has a lot of things it can do or is asked to do, what should the TAG prioritize in the coming year?

The area of the TAG's work that I'm particularly interested in helping with is feature design reviews. In my work on web standards I've been on the receiving end of these reviews a number of times, and I've seen the TAG give insightful and useful advice. When the TAG is working at its best, their feedback can be a really valuable part of the development cycle of a web platform API. They can point out issues of a broader scope that the working group might have missed, flag accessibility or privacy implications of a design, and identify interactions with other evolving features. Something I'd really like to see is if we can make design reviews more useful and more responsive, more browser engines might see enough value there to bring them into their web API development process.

The TAG should triage horizontal reviews alongside its feature design reviews. Learnings from feature design reviews and horizontal reviews can lead to work in other areas; problems commonly encountered could inspire more generalized investigations or may inspire Findings, Statements, or other written guidance.

The average design review latency is a good barometer to watch. As this falls to a reasonable threshold, it's a signal that the TAG has more time to spend on more generalized findings. As review latency rises, that's a signal to refocus on review requests.

What kinds of reviews should go to the TAG, how should the TAG triage reviews, and how can you help the group be more comfortable rejecting reviews it doesn't have time for?

The TAG should be open to reviewing anything potentially impacting web architecture. This can include early design reviews, reviews for mature specifications, and horizontal reviews.

First-in-first-out is a good baseline to fall back to when all else is equal, but triage can depend on multiple factors. In some cases it should be influenced by context from the requestor; for example, reviews for features that are about to ship can receive priority. It can also make sense to put smaller reviews ahead of much larger reviews that could take significantly more time.

The TAG should aim to communicate beforehand if a review is expected to take extra time. It will be helpful for requesters if they can know what to expect. If the TAG doesn't feel that it has time for a given review, that can be the start of a conversation with the requester. Maybe there's some smaller subset of the functionality that they would like the TAG to comment on, or maybe the TAG can suggest other experts who can take a look.

Do you want the Team to release the anonymized ballots from this election? Why or why not?

Since releasing anonymized ballots was not built into the process prior to the start of the nomination period, and as far as I know has not typically been done in TAG elections, it seems late to make this change now. I have no particular objection to doing so in future years as long as the decision is made prior to the start of the election process with sufficient time for members to object.

The TAG has a problem with members failing to show up and do the needed work. How much time do you have to commit to TAG work? Do you have travel or scheduling constraints?

I have buy-in from my employer to set aside the time to make significant contributions that will fulfill my obligations as a TAG member.

What skills, expertise, and perspectives do you have that the continuing TAG members and other TAG candidates lack?

I have been Microsoft's representative in the Interop Project for about 3 years. The Interop Project is a collaboration between browser implementers that aims to identify parts of the web platform that are standardized but not universally or consistently implemented, with the goal of focusing development energy on these areas to make them interoperable. In Interop I've worked to channel feedback from web developers about which areas of the platform are causing them the most trouble, and I've advocated for process changes that would make the group more accountable to developers. To be effective in this role I've had to have the ability to build cross-organizational consensus around areas that are important to developers and users.

Working in the Interop Project has particularly impressed on me the importance of ensuring alignment between browsers on emerging web features. Inconsistently implemented APIs are a major source of frustration for developers. The TAG can help here by reviewing proposed APIs with an eye towards building cross-browser consensus, seeking to avoid bias towards the needs of any particular organization or browser implementation.

If you disagree with a feature's design, how will you decide between just saying that it's bad, vs trying to improve its design as much as possible?

I try very hard not to give negative feedback without working with the other person to find a way forward towards improvement. So if I think a design is unsound, I'll work with its proponent to explore the specific problems. I'll brainstorm changes that would bypass those problems and encourage the proposer of the design to do the same. If the problems with the current design seem insurmountable, I'll help them look for alternatives to explore. The TAG's role should be to help people design the best version of a feature that reduces or avoids negative impacts, rather than opining on whether the feature should exist at all. The goal is to always set people up with constructive, actionable feedback rather than just saying "this is bad, try again".

Can you show us an example of a time you found a way forward between people who initially disagreed strongly?

The journey to reaching consensus on JSON and CSS module scripts followed this kind of path. Concerns were raised about an aspect of the design being a potential security concern, and while there wasn't broad agreement on whether the issue amounted to a security issue in practice, it became clear that the proposal in its current form was not going to receive broad support.

I worked with several others to champion a proposal in TC39 adding a new JavaScript syntax to mitigate the security concern. This involved brokering a lot of discussion between people in TC39 and the HTML spec editors, and ultimately we built a consensus that allowed JSON/CSS module scripts to move forward; all browsers now have positive positions on these standards.

What mistakes has the TAG made recently?

It would be a bit strong to characterize it as a mistake but I still think there's progress to be made in bringing down design review latency. The TAG gets swamped by a lot of requests, so there is understandably a lag before they can pick up a review; sometimes that can be a significant delay. Unfortunately this can lessen the usefulness of the feedback. The shape of an API can change in the course of development, and since teams can't always wait indefinitely sometimes features can even ship in the interim. And the later in the development cycle that feedback comes, the more difficult it is for teams to make broad changes.

So if elected my main priority will be for me to do what I can to reduce the review latency without compromising review quality. In the most straightforward sense this just means dedicating the time. I'll apply myself diligently and I'll have the time built in to my schedule to do the work and pull more than my share of the weight in making sure reviews happen in time.

I'm also interested in looking at process changes that can help speed things up. I know the TAG is already looking at a program to pull in outside expertise to help with reviews, and I'm really excited about that. I'd like to help move that forward, as well as taking a look at other things like the way reviews are triaged to see if there are other opportunities to streamline things, and to generally be open minded about possible process changes or experiments.