Meet the 2024 TAG Candidates: Sarven

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 web is a constantly evolving reflection of society, and its architecture must evolve alongside it. I've emphasised this in the opening vision of my TAG statement, in the context of working to meet societal and environmental challenges on a global scale. The Architecture of the World Wide Web, Volume One (AWWW) has served as a foundational explanation of the web's core design components, but the story continues. We must continue developing the web architecture, revisiting it with the benefit of two decades of hindsight, and incorporating advancements in standards, implementation practices, and lessons learned. This ongoing development will also inform and support the evolution of web platform standards and principles.

If elected, I will contribute to ongoing efforts (and put out fires), review explainers, revisit the loose ends in AWWW Volume One, and initiate discussions to develop a Volume Two. This work will ensure that the web continues to function "for all people" based on our refined understanding and progress to date.

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 group might benefit from conducting and publishing a self-review to evaluate its scope and priorities. That aside, the TAG should focus on "high-level" web architectural needs and design principles. We should develop a roadmap to advance the web's architecture by building on the lessons from AWWW. Additionally, it should initiate and facilitate discussions about anomalies, ambiguities in principles, as well as identify technology or standards gaps (or traps).

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?

I would work with the group to develop criteria or guidelines to inform the community about the kinds of reviews that are worthwhile to seek. This could include clarifying when a proposal falls outside the TAG's scope or when its implications do not warrant architectural scrutiny. By refining the triage process and creating transparent rejection practices, the TAG can better allocate its time to work with the most architecturally significant proposals, without necessarily undermining specification orthogonality.

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

Yes, I believe the release of anonymised ballots is valuable. It can help us to determine whether there is a pattern of backgrounds, experiences, affiliations, or other areas of focus that impact voting.

I have shared my findings based on the Solid CG chair election, along with data that could serve as some input for this discussion to help the W3C community consider additional perspectives and factors.

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've been a dedicated chair and contributor to specifications as an editor and author, see, e.g., work items. I've also been an active participant in meetings, whether as chair or scribe, see, e.g., meeting records and ecosystem monitor. I can commit to face-to-face meetings, with a strong preference for locations accessible by land or sea. As an IE, I will either cover my own travel expenses or seek travel support.

Having worked with contributors from a range of backgrounds, I'm acutely aware of the constraints and impediments to full participation in the W3C community, whether these relate to personal home life, cultural/language differences, geographical location, disability, and other needs. How does the TAG accommodate these diverse access needs in its workflow? I'd like to help ensure we can adapt our processes to enable participation by all members.

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

I can provide a perspective to TAG rooted in my experience with web architecture, including protocols, data structures, and implementation-driven specification development. I have decades of experience in implementing standards as a web page author.

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?

As mentioned in my TAG statement, "prioritising community needs and building consensus around often conflicting interests" has become a second nature to me. I will raise any outstanding disagreements with other TAG members or the community for a sense check, then investigate the possibility to work through alternative or refined proposals based on consensus.

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

I see conflicts as opportunities to make something better. The Solid QA came out of a resolution to a strong social and technical conflict among some participants in the group. I've proposed the QA charter and carried it out with the CG. The QA document became a mutual understanding between contributors to technical reports, test suite software maintainers, and software implementers by following a cooperation process.

What mistakes has the TAG made recently?

This is more about what is capturing the TAG's attention and its limited time and energy, rather than a "mistake". From the outset, it seems that TAG is often overwhelmed or predominantly focused on the needs of browser vendors. In my view, the "architecture" in the Technical Architecture Group should not be overly focused on browser APIs or lower-level details of individual features - we already have experts in the community addressing these things. Conversely, due to constraints in time, energy, and expertise, some higher level or more broadly impactful reviews may be concluded more quickly than the attention they truly merit.