Before I start on my thoughts, if you work for a W3C member organization, please head to the 2023 TAG Election page. Voting is open until 2023-12-14.

If you are considering how you might like to rank me when voting, read on. I can’t promise that this post will provide much additional context, but it might.

The W3C TAG is a bit of a strange institution. The TAG occupies a position of some privilege due to its standing within the W3C and the long-standing participation and sponsorship of Sir Tim Berners-Lee.

The TAG also has a history marked by notable documents produced under its letterhead. The TAG, through its findings, has been responsible for recognizing and analyzing certain key trends in the evolution of the Web, providing some key pieces of architectural guidance. The TAG also publishes documents with general guidance for people seeking to improve the Web, like design principles and a security and privacy questionnaire.

On a day-to-day basis, however, the TAG provides hands-on guidance to people looking to add new capabilities to the Web, primarily through design reviews. Records of early reviews trace back to 2013 in the TAG repository, but the practice has deeper roots.

The modern review record starts with a meager 5 reviews in the latter half of 2013. More recently, the TAG closed a total of 85 design reviews in 2022^[1]. Already, in 2023, there have been 106 design review requests opened.

The function of the TAG as a body primarily focused on reviewing new Web APIs is one that took a while to settle. A key driver of this increase in volume has clearly been the inclusion of TAG review as a formal precondition for shipping Web-visible changes in the Chromium project. Chromium consequently drives a lot of this review load with 73 of the 106 new requests that arrived in 2023 clearly marked as originating from “Google”, “Chromium”, or “Microsoft” as a primary driver or funder of the work^[2]. That is nearly 70% of the total review load attributed to Chromium. This is in addition to those design reviews that were initiated on behalf of a W3C group in which Chromium contributors were instrumental in the work.

Obviously, at a rate of more than 2 reviews a week, that’s a fairly major outlay in terms of time for the TAG. Proposals vary in size, but some of them are quite substantial. A good review requires reading lengthy explainers and specifications, filling gaps in understanding by talking to different people, considering alternative options, and building an understanding of the broader context. A proper review for a more substantial proposal can take weeks or even months to research, discuss, and write up.

The TAG is expanding in size this year. An increase to 12 members (8 elected, 4 appointed) does give the TAG more capacity, albeit with added coordination costs reducing efficiency. This is predicated on the idea is that reviews are the most important function of the TAG. That being the case, then adding more capacity seems like a reasonable reaction.

That an action is superficially reasonable is not the standard to apply when making such a decision. As with a design review, an examination of the alternatives is generally illuminating. Once those alternatives are understood, we might again conclude that the proposal on the table is the best possible path, but we do so with a more complete understanding of what opportunities are lost or foreclosed as a result. The AB minutes of the decision do not reflect that process, but then they are only responding to a request from the TAG.

There are several other equally reasonable ways of dealing with increased workload. If reviews are taking too long, it might be possible to find ways to make reviewing easier or faster. Perhaps the TAG has exhausted their options in that area already. Maybe they have looked at selectively rejecting more design review requests. Maybe they have considered finding ways to offload review work onto other bodies, like PING.

From my limited perspective, it is not clear that these avenues of investigation have been fully explored. For instance, I have good experience with effective directorate system that the IESG uses to greatly alleviate their workload, but I see no evidence of an effort to delegate in a similar fashion.

TAG members each volunteer time from their ordinarily busy day jobs, so any excess load spent on reviewing is time that is not available for higher functions. In addition to review load, the TAG has a role in W3C Councils and other critical procedural functions in the W3C process. Those tasks are generally not easily delegated or dealt with by a subset of TAG members.

I am supportive of efforts to better use the TAG in for key procedural functions, like the W3C Council. Those functions make the TAG more important in a good way. The W3C needs people in the role who have good judgment and the experience to inform that judgment.

Along with that, it is important to reserve some space for the TAG to provide technical leadership for the W3C and the Web community as a whole. After time spent on the procedural functions demanded by the process, design reviews have the potential to completely drain any time TAG members have to dedicate to the role, leaving no spare capacity. Ideally, there needs to be some remaining space for the careful and thoughtful work that leadership demands.

Effective technical leadership depends somewhat on the TAG being exposed to how the platform is evolving. Reviews are a great way to gain some of that exposure, but that does not mean that the TAG needs to review every single proposal.

I don’t have a specific plan yet. If appointed, it will take some time to understand what the role is and what options are available. I consider myself quite capable of performing that sort of review and I expect it would be easy to settle into that function. But I have no intent of letting design reviews dominate my time; the TAG – and the Web – deserves better.