The W3C Technical Architecture Group (TAG) is responsible for the stewardship of the Web’s architecture. Formally, that means documenting and building consensus around principles of Web architecture, helping resolve architectural issues, and coordinating architectural work across technologies and communities.
In practice, serving on the TAG means something broader: regularly looking at technologies you may know well alongside technologies you have never encountered before, and asking what their design means for the Web as a whole.
If you’ve never considered running for TAG or nominating someone for TAG because you weren’t really sure it was a good “fit” or what it entailed, this document is for you!
A substantial part of TAG’s work is reviewing emerging Web technologies. Working Groups and other standards developers bring proposals to the TAG for architectural review, often while those technologies are still being designed. The TAG works with those groups to identify architectural early concerns and suggest ways to make their designs fit coherently into the Web.
The TAG also develops broader architectural guidance, including the Web Platform Design Principles, TAG Findings, and other documents that address questions extending beyond a single specification.
TAG is also part of last resort resolution of Formal Objections.
Nobody is expected to be an expert in all that we do, but everyone is expected to participate.
That means reviewing work where you have relevant expertise, bringing that expertise into broader TAG discussions, and also being willing to read and think about areas that are less familiar.
You should plan on at least one business day a week, and sometimes more. And travel internationally at least two times per year (more below).
The TAG currently holds a plenary call every other week and breakout calls every week. Members are expected to participate in two breakouts each week (plus the plenary, when it’s held), although the particular meetings may depend on timezone and the work being discussed. There is also substantial work outside meetings: reading specifications and explainers, participating in design reviews, discussing issues on GitHub, reviewing documents, and contributing to TAG publications.
The workload is not perfectly predictable. Some weeks are busier than others, depending on the reviews and other work underway.
The TAG also meets face-to-face three times each year, including TPAC. Remote participation is supported, and members can participate effectively without attending every meeting in person. That said, the face-to-face meetings provide a level of sustained, high-bandwidth discussion that is difficult to reproduce remotely, and members who can attend in person generally get more out of them.
W3C does not fund TAG member travel. Prospective members should therefore consider not only the time commitment but also whether they have employer, sponsor, or personal support for travel if they expect to participate in person. This can be upwards to US$10,000 per year when you factor in flights, accommodation, meals, etc.
For many members, the time commitment and additional travel are the hardest practical parts of the role.
The TAG needs a wide range of expertise and a variety of viewpoints. Web architecture reaches across security, privacy, accessibility, identity, protocols, internationalization, distributed systems, user experience, and many other areas. The TAG benefits from having people who approach architectural questions from different technical backgrounds.
What matters most is not simply the depth of your expertise in one area. It is whether you can use that expertise to think about broader consequences.
A security expert, for example, should be able to ask not only whether a particular design is secure, but what assumptions it introduces into the Web platform. Someone with identity expertise should be able to consider how an identity mechanism affects privacy, user agency, interoperability, or architectural layering. Someone with implementation experience should be able to think beyond what works well in one particular implementation.
Depth matters, but so does the ability to look outward from it.
There is no single ideal background, and diversity of experience is important. Effective TAG members, however, tend to share several characteristics.
They can reason about architectural consequences beyond the specification immediately in front of them. They are willing to read outside their own specialty and learn enough to participate meaningfully in unfamiliar discussions. They can explain technical concerns constructively rather than simply declaring that a design is wrong.
Participants are also willing to speak up and share their views or indicate when they do not understand a certain point, either from a technical perspective or because of language barriers. Asking naive questions is a superpower.
They are also comfortable grappling with ambiguity. TAG reviews rarely present tidy problems with one obviously correct answer. The work often involves understanding competing constraints, deciding which concerns are genuinely architectural, and working with other people toward a conclusion that can command consensus.
That makes consensus-building an important part of the job. You do not need to agree with everyone, and healthy technical disagreement is part of TAG work. You do need to be willing to listen, reconsider your own assumptions, and help the group reach useful conclusions.
TAG participants serve as individuals, not as representatives of their employers, sponsors, or particular standards communities. That independence is fundamental to the role; your sponsoring organization needs to be comfortable with you having views independent of theirs.
Everyone brings experience shaped by the organizations and communities in which they have worked. The expectation is not that TAG members somehow stop having perspectives. It is that they exercise their judgment in the interests of the Web as a whole rather than advocating for a particular company, product, implementation, or technology.
That can mean questioning assumptions that are common within your own professional community. It can also mean supporting an architectural approach that is not necessarily the one your employer or the technology community you know best would prefer.
If you are looking for a role in which you represent your organization’s technical position, the TAG is probably not it.
The obvious answer is time.
One day per week is a reasonable minimum, but substantive reviews and document work can take more. Three face-to-face meetings a year also represent a meaningful travel commitment for those who attend in person.
The less obvious challenge is the breadth.
On the TAG, you may spend one discussion looking at a browser API, another considering an identity or payments mechanism, and another thinking about a fundamental question involving URLs, user agents, privacy, or the relationship between the Web and an emerging technology.
You will frequently encounter work outside your immediate expertise. That can be uncomfortable, but it is also one of the most interesting parts of serving on the TAG.
Few roles offer the same opportunity to see such a broad cross-section of technologies being proposed for the Web and to think about how they interact before many of those architectural choices become difficult to change.
If you want to learn about a wide array of web technologies and influence them in good directions, and you can find the time and budget, you should consider running. Don’t let your own doubts about your expertise get in the way—people without those doubts are generally less qualified. Ask some peers in your working groups, and/or current TAG members, whether they think you’d be a good TAG member, and if they think so, please run.
You do not need to know everything about the Web platform, and you should probably be suspicious of anyone who thinks they do.
You should consider the TAG if you have substantial expertise in some part of the Web or Internet ecosystem and are interested in using that expertise to reason about larger architectural questions.
You should also be prepared to read a lot, ask questions when you do not understand something, spend time on work outside your own specialty, disagree constructively, and make a real weekly commitment to the work.