Skip to main content

My answers to the “Meet the AB Candidates” questions

Hi, I’m (she/her), and I’m for W3C’s Advisory Board (AB).

A number of questions were put to the candidates during three “Meet the Candidates” sessions on May 20th. The sessions were really fun to participate in and very informative. It’s taken me to turn my extemporaneous answers into more considered text, but here are my answers to each question.

What are the challenges facing W3C as an organization in the next two years, and what skills and interests will you bring to the AB to help with addressing them? #

One of the questions Seth put to the AC during his presentation at the spring AC meeting this year was: “How do we make it more interesting and appealing to do standards work at W3C?” It’s not a given that people will bring work here—web technologies get defined at several different SDOs today. We can’t afford to take our place in this ecosystem for granted. We ought to distinguish ourselves from similar SDOs by the effectiveness of our processes, as well as the timeliness, relevance, and technical rigor of our specifications.

Much of what Seth covered on his “Fit for Purpose” slide resonates with me as well:

Instead of trying to a priori identify what needs improving, the AB should directly engage with the people doing technical work to identify areas ripe for improvement.

I’d like to spend time looking at W3C’s collaboration with other SDOs. We’re not the only standards body, not even for Web technology. We should always be monitoring the health of and seeking to improve our collaboration with Ecma, IETF, WHATWG, Unicode, and other such organizations.

Another thing is incubation. We’ve been running experiments for years around this, and it’s time we seriously engage with the question of if, how, and where to formally incorporate incubation into our process.

The AB has been discussing its role in the community and how it may need to be updated to reflect the new governance structure. What do you think the AB’s role is, and what do you believe the AB needs to do to fulfill it? #

The W3C is a standards body. The purpose—the core function—of standards bodies is to be places where people gather to work on specs. When we succeed, we produce well-specified standards which precisely and unambiguously describe the behavior of widely-deployed, interoperable implementations.

The various responsibilities vested in the AB by the Process document are all geared toward ensuring the effectiveness of W3C at fulfilling its function. As I said in my candidate statement, it’s the AB’s job to be attentive to the entire membership and to strive to address its concerns. Fundamentally, the AB is here to support W3C’s participants so they can do their best work. It’s here to help.

The first order of business of the new AB should be to directly engage with the people doing day-to-day spec work—editors, chairs, and other contributors—to identify the top issues getting in their way. Once we know what the actual ground-level roadblocks are, we can work to address or mitigate them.

What do you think of the W3C Strategic Roadmap presented at AC2025? Which parts in it do you think W3C should prioritize in the coming year or two? #

If elected to the AB, I’d be most eager to work on Structural Evolution and Stakeholder Strategy out of the strategic initiatives Seth identified in his presentation. Though of personal interest to me, work on Technology Strategy is better suited to the TAG.

Which AB priority projects do you want to personally spend time working on? #

On the existing list, I’d look to spend time and engery on:

I believe my years of experience as an AC Rep, a TAG participant, a Chair, and an Editor could be usefully brought to bear on these projects.

Missing from the existing list, though related to those four, are:

What do you as an AB candidate believe W3C should be doing about the impact of AI or other emerging technologies on the Web? #

The role of the AB is to enable and facilitate spec work, not to influence the technical substance of that work. Technical leadership on this and other questions is the domain of the TAG. That said, this strikes me as a great question to bring to the new Exploration IG, which is charted to grapple with whether and how we should engage with emerging technology trends at W3C.

How important is consensus to you and how important do you think it is to W3C? What are the tensions between moving fast and getting consensus? #

Consensus is one of our core values, and one I deeply believe in. Our definition of consenus is when “a substantial number of individuals in the set support the decision and there is no sustained objection from anybody in the set.” Some thoughts:

  1. Who is in the set? Are there people present who can speak to the needs and concerns of everyone affected? It’s easy to find consensus in small, homogeneous groups, but such consensus is weak. The more diverse the voices heard in the consensus-making, the wider the net is cast, the better.
  2. We need to wary of “consensus by exhaustion”—when we come to consensus not by addressing concerns but by wearing down the concerned individuals until they disengage. This may technically fit the definition of consensus, but it’s shallow. It doesn’t live up to our values. We can and must do better.
  3. It can be useful sometimes to ask an objector “you may not like the proposal, but can you live with it?” In our eagerness to make forward progress, it’s tempting to reach for this question early, but this risks not giving concerns due consideration. Our decisions are more robust and better stand the test of time when we can confidently say that we really grappled with each issue that came up.

How do we encourage diverse voices to participate in the community, particularly those who don't have the support or time from their employers? Not everyone who uses the web can afford to participate. #

There are so many barriers to participation in standards work: the cost, both financial and in terms of the time commitment required, language barriers, meetings at all hours of the day and night, just to name a few.

Re: financial barriers, the current AB has made some progress towards addressing the need for an Invited Experts fund for those who serve on the elected bodies, and has asked the Team to investigate funding the IEs’ travel to WG meetings. There was also progress in the past toward reducing or eliminating the TPAC attendance fee. We can and should do more here.

There are social barriers to participation too. Anecdotally, I’ve heard from a number of web developers over the years that, when they’ve tried to file issues on specs, it’s not gone well. They feel unwelcome, or they’re left with the impression that their idea got dismissed out-of-hand. But it’s precisely this kind of feedback from web developers that we need! It’s one of the ways we ensure the relevance of our work. If people are discouraged from filing issues in the future, we’ve done them and ourselves a disservice.

Not all of these barriers can be addressed by the AB. Some should be taken up by the Board of Directors, by the Team, or by the individual Members themselves. I think the AB ought to focus on identifying and reducing barriers getting in the way of everyday web developers.

Early in W3C’s history, the tech industry collaborated on specs in SDOs, then implemented interoperable interfaces in their proprietary products. Now, for example the various LLM interoperability APIs, they collaborate in OSS projects, which define de facto standards, which then may or may not get refined and ratified by SDOs. 
How should the W3C Process and culture confront or adapt to this pattern? #

Sometimes the people working on specs notice problems and propose solutions to them before implementations have a chance to experiment in the solution space. Sometimes the opposite is what happens—implementations experiment with features before bringing them to W3C for standardization. Most of the time, though, you can’t fit what actually happens into a fully-prospective or fully-retrospective model. There’s a push and pull between active experimentation and maintenance in implementations and ongoing spec work. This back and forth of implementations getting ahead of specifications and vice versa has been around since the beginning.

That said, there’s likely a lot of modern OSS practices and aspects of its culture that could be productively applied to spec work. The almost universal adoption of Git and GitHub for most spec work at W3C is, I think, an example of such borrowing that’s already occurred.

There’s also things that OSS communities can or should learn from the standards world. For instance, programmers sometimes view diversity of implementation as a burden, as a source of problems. “Why does my website work in this browser but not that one?” There’s an opportunity here for us to articulate the value of a diverse implementation ecosystem. How it makes our technology more robust, easier to adopt, and more likely to stand the test of time.

Please talk about your experiences in leading organizations, specifically with members having different interests. How might you bring that experience to work on the AB? #

At the end of the day, specifications are made by people. Many of the skills that we build up during the resolution of complex technical disagreements are really centered around resolving interpersonal conflict.

Participants in standards work arrive with different goals, motivations, and premises. We may weigh each consideration differently from one another. It’s not a great analogy, but I’ve found that resolving disagreements often feels like “debugging the people” involved rather than the technology produced.

I learned the notion of “aviate, navigate, communicate” from Eric Siow, and I’ve found that structure very helpful when encountering a disagreement. Figuring out which case you’re looking at is the first step to finding a resolution.

It’s important to remember when encountering a disagreement that you never have all the information at first. It may seem like a disagreement over API shape or what-have-you, but usually there's some kind of underlying disagreement about principles, or priorities, or who we’ve included as relevant constituencies in our analysis of the problem space.

Surfacing the underlying disconnects can help people come to agreement, because sometimes it turns out that people actually agree on the underlying principles, but just hadn’t been able to see it.

Another approach, which sounds counter-intuitive, is to choose to be unambitious. That is, maybe it’s not obvious how to resolve the big disagreement but, if you break it down into smaller pieces, maybe you can progress some of the pieces. This is important in at least two ways:

It's easy, as engineers, to focus on the technical issue and forget that we're also part of a community, and we're building a community. The people you work with in these WGs, you develop friendships or working relationships. Most of these interactions aren't one-off things. It helps to remind people that you're going to have to talk to this person next week in the next meeting about a different problem. So, focus on healthy relationships, building trust, and helping people realize that not everything is a hill worth dying on.

Do you have any kind of ideas of how to improve Member engagement and get more feedback on the operation of W3C? How can we get more engagement and involvement from the membership? #

When Igarashi-san asked this question, my first thought went to the AC. I’m an AC rep, so it’s natural to interpret this question as something like “How can we get the AC more engaged? How do we encourage more vibrant, active discussions within the AC?” And that is absolutely something worth working on.

But the membership is much bigger than the AC. Member companies send a lot of people to a lot of groups, and they are who we need to prioritize. We need to