Meet the 2024 TAG Candidates: Marcos

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 most important problem is maintaining platform cohesion amidst rapid innovation. With many working groups and implementers driving new technologies, fragmentation can occur, hindering interoperability and developer adoption. If elected, I will leverage my extensive experience and leadership roles to enhance cross-group coordination, engage the right experts when needed, and promote technical leadership. This will ensure the web platform advances cohesively, benefiting users and developers worldwide.

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 TAG should prioritize:

Advancing Privacy and Security Initiatives: Continue efforts to move away from third-party cookies and develop privacy-preserving alternatives.
Enhancing API Design Guidelines: Update and maintain clear guidance to help developers and spec authors create consistent, user-friendly, and interoperable APIs.
Facilitating Collaboration and Interoperability: Improve coordination between working groups to prevent fragmentation and promote a coherent set of web technologies.

By focusing on these areas, the TAG can address immediate challenges while laying the groundwork for a secure, private, and inclusive web.

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 focus on reviews that have significant architectural implications, involve cross-cutting concerns like privacy and security, or introduce new paradigms. To triage effectively, the TAG can set clear focus areas and encourage proposers to seek initial feedback from relevant working groups. By communicating transparently about priorities and capacity, and providing constructive guidance on alternative paths, the TAG can manage its workload while still offering valuable input on critical developments.

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

Yes, I support releasing the anonymized ballots. Transparency is essential for building trust within the community. It allows us to understand participation levels, hold the membership accountable, and identify areas where more outreach is needed. Releasing anonymized data, while protecting individual privacy, contributes to the health and inclusivity of our organization.

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?

It's important to acknowledge that TAG membership is not a ceremonial role; it requires active participation and commitment from all elected members. While people are busy and have limitations, we need to recognize that fulfilling our responsibilities effectively demands dedicated time and effort. If elected, I am prepared to commit the necessary time to TAG work, including meetings, reviews, and collaborative projects.

By setting realistic goals—focusing on a manageable number of projects, reviews, and findings—we can ensure we don't overload ourselves and maintain high-quality outcomes. Acknowledging our limitations allows us to prioritize effectively and deliver meaningful results. I have flexibility in my schedule and no significant travel or scheduling constraints that would impede my active participation.

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

I bring nearly 20 years of extensive experience in web standards development, with proven leadership as chair of key working groups (WebApps WG, Media WG, establishing the WICG, Payments WG, and so on). My work has had a broad impact on the web platform, and I have a strong commitment to interoperability, privacy, security, accessibility, and internationalization. Additionally, I value collaboration and am willing to engage with diverse communities, recognizing the importance of external expertise to enhance our outcomes.

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

I approach disagreements constructively by first understanding the underlying use cases and motivations. I encourage exploring multiple solutions and evaluating them against core web principles like privacy, security, and accessibility. My goal is to collaborate with stakeholders to refine multiple designs, ensuring they align with the long-term health of the web. If a feature poses significant concerns, we provide clear, evidence-based feedback and work towards a better solution that weigh the pros and cons of each proposal.

In short, make sure that there is a sense of shared ownership and responsibility by both the TAG and those proposing something new. All features must be seen as a "common" resource, by the W3C and in the interest of users - not those proposing it.

However, I am adamant that sometimes the TAG must push back on proposals that could harm user privacy or compromise essential values of the web - or work together with those proposing a feature to find a better solution. In such cases, it's important to constructively apply "stop energy" to prevent potentially harmful technologies from moving forward and find a better path forward. Upholding the core principles of the web may require us to say "no" to certain features to protect users and maintain trust in the platform. However, the TAG must always articulate why a solution might not be ideal, and where possible help with finding some alternative that meets a particular use case or need.

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

Two recent examples from the last year alone are below, but this has been an extremely common experience:

Digital Credentials API

During the development of the Digital Credentials API, there were divergent views between browser implementers and other stakeholders unfamiliar with browser architecture. I facilitated discussions to bridge knowledge gaps, explained the critical role of browsers in user security, and collaboratively refined the design to meet security needs while addressing stakeholders' objectives. This led to a consensus on a secure, functional specification, demonstrating that incorporating diverse perspectives can lead to elegant solutions.

Pending Beacon API

In the case of the Pending Beacon API, there was disagreement within the WebKit and the W3C community about its necessity and design. By engaging in open collaboration, we discovered that the desired functionality was essentially a special case of the existing Fetch specification. Through collective input and examining different perspectives, we adapted the proposal to integrate with Fetch, resulting in a better, more streamlined design. This experience highlights how gathering extensive input and considering various viewpoints can resolve conflicts and lead to improved outcomes.

What mistakes has the TAG made recently?

One area for improvement is that the TAG has occasionally overestimated its expertise, providing guidance without fully consulting external experts. This can lead to less informed decisions. Moving forward, the TAG should embrace humility, acknowledge when it lacks specific knowledge, and proactively seek input from specialists and the broader community to enhance the quality of its guidance.