Hi there. Welcome to this talk, which is gonna be about the Technical Architecture Group within W3C.

And welcome to the virtual Advisory Committee meeting.

I hope you're all keeping well.

So, today we're gonna talk about the Technical Architecture Group, I'm gonna give you a brief update about, what's been going on with us, and hopefully leave you with some information about our activities and how best to engage with the TAG going forward.

So first of all, what is the TAG?

For those of you who've been participating in W3C Advisory Committee Meetings for a while, in the W3C community for a while, this information won't be anything new to you.

But I'm gonna go through it in any case.

So first of all, the TAG is a group made up of people from different organizations.

It's a partially elected and partially appointed body.

We have one permanent Chair who is Tim.

We have Rossen from Microsoft, myself from Samsung.

Alice from Google, Kenneth from Intel, Peter Linss who also co-Chairs, who's an Invited Expert.

David Baron from Mozilla, Hadley Beeman who is an Invited Expert, and also works for the UK Government.

Yves Lafon, who's our staff contact, Sangwhan Moon from Odd Concepts, and finally Tess O'Connor from Apple.

So what is the TAG?

W3C TAG is a special group that's chartered to document and build consensus around the principles of web architecture, to interpret it and clarify these principles when necessary, to resolve issues around general web architecture issues that are brought to the time.

And to help coordinate cross-technology architecture developments inside and outside of W3C.

So that's all from our charter, which you can get from reading that as well.

What's the TAG currently working on?

We do a lot of pondering deep questions and having deep thoughts about the web.

But primarily we focus on writing things.

A lot of our output in terms of documents, tends to be things called "Findings", where the TAG will have a particular idea, or particular opinion, that it wants to express.

And so we write that down in the form of a Finding.

We also have other kinds of documents, other outputs, and I'll talk about a few of those.

Most of the output of the TAG comes in the form of design reviews.

So this is a little bit harder to quantify, because generally our design reviews are written up in GitHub Issue Registries.

They consist of information that we're imparting to other spec authors and questions that we're asking, answers that we're receiving.

They're more conversational in nature, but I'll get into that as well.

We also do joint work with other groups, which can lead to publication of documents.

The Security and Privacy Questionnaire is one example of that.

And we play a role in cross-organizational liaisons, especially where that liaison work has to do with some architectural element of the Web Platform.

HTTP would be a good example where we, in the past, have a lot of work, together with the HTTP Working Group, especially when we were in the process of moving to, the development of HTTP/2.

We also have done some developer community engagement, although in the current situation we are not able to do that as much, obviously because that has been predicated on the idea that we're meeting in different places around the world.

And so we would take that opportunity to also engage with developers around the world.

So that segues nicely into -- I just wanted to talk a little bit about how do we TAG during a pandemic.

I think this might be useful to anybody who's running any kind of enterprise, but especially W3C Groups, and trying to keep W3C Groups up and running during the current situation that we have, or we might be used to meeting face-to-face on a regular cadence.

It's quite useful to think about how that now can take place at least temporarily on a purely virtual environment.

Obviously one of those, and when evidence of that, has been the development of the, or the transition of the AC meeting into a purely virtual meeting which you're experiencing now.

So you can feedback on how relevant and how happy you are with that approach.

As far as the TAG goes, we're really continuing our cadence of weekly meetings.

And we actually have four weekly video calls that are, we have three Breakout Calls and one Plenary Call.

The Breakout Calls are really for discussing particular issues.

And that's where we do most of our work around design reviews.

We break those out into those breakout sessions so that we can have more involved discussions about particular issues.

And those calls are at different times to accommodate different time zones.

So we actually have three different calls, and the idea is that every TAG member should be attending at least two of those calls.

Because one of them is probably gonna be at a time that is not very convenient for them.

And then we also have one Plenary Call, which is intended for all TAG members to attend.

And during the Plenary Call we read out what happened during the Breakouts, we also do other work of the TAG, especially focusing on documents.

So for our face-to-face, we have shifted to a "Virtual face-to-face," with a 5-day schedule.

We're actually having that also in May, the week after the virtual AC meeting.

All of those 5 days of meetings will be half day sessions, which will be at different times again to allow for different time zones.

By the way, we're using jitsi.org, which is an open-source WebRTC implementation for all of our calls with reasonably good results.

There is still some issues around browser compatibility with Jitsi.

They're working on it, the different browsers are working on it.

But in general, we're having a pretty good experience using Jitsi for all of our calls.

So, segueing to the talking a little bit about design reviews and which we call the TAG's, "Heartbeat." All of these design reviews take place, in our Design Review repo in the Issues registry.

And they're intended for people that want to request a review from the TAG.

They request us to take a look at the work that they're doing.

Ideally that is happening in the design phase, which is why we call them design reviews.

However, we do have three different issue templates.

And the way that people create an issue, create a design review, they initiate a design review with us is to open up an issue, at which point they're presented with three different issue templates.

One for an early design review.

If the spec developers have an idea but probably not in implementation yet, or maybe they're very only, very early in the phase of implementation.

They may not have a clear idea of where in W3C, or where elsewhere, what venue this is gonna go into.

That could be a good candidate for an early design review, where you just wanna get the TAG's opinion.

We also have a Specification Review for where, for specifications that are further along, in the development process.

They could be already in design, they could be already in a spec development within WICG or within the community group or within a working group.

We also have a template for Dispute Resolution, which is specifically where somebody in a Working Group, ideally the Chair, but it could be somebody else, wants to get the TAG's opinion on a dispute that's currently happening in a working group or between two Working Groups.

When you're requesting a design review or a Specification Review, we ask you to write an Explainer.

And we have a whole document which is linked from the link that I provided below, https://tag.w3.org/workmode, which explains what an Explainer is.

It's been a little bit of confusion about the Explainer.

So just to reiterate, what I have been telling a lot of people.

The Explainer is not something that we want you to write for a TAG review.

It is not intended solely for the purpose of the TAG to help us review whatever you're building.

We've encouraged people to write an Explainer because we feel like it's good practice to write an Explainer.

And the Explainer, the idea of the Explainer is to explain what the thing, that's being written in clear language.

So that's why we really encourage people to start with user needs.

Think about what the user need is, that you are trying to solve or to service with this new technology.

That usually helps to clarify for people reading the specification or reading the Explainer, what it is that they're reading;

why this technology is being produced.

We also have a lot of questions that we'd like to ask in terms of what is the venue?

What is the approach here?

What other technologies have been considered?

That kind of thing.

So there's a kind of template that we ask people to follow.

And I'd be more than happy to talk to any group chairs or any members of the AC, or anybody to clarify anything about this in terms in terms of how we think Explainers should be written, because we think they can be a very useful and powerful tool for people that are developing specifications.

So what happens during the TAG review?

One TAG member will usually step up and own the issue, but usually it's two TAG members that come and assign themselves at least to each particular issue.

We then will likely invite somebody to join us maybe on a call or maybe at the face-to-face, or maybe just in the discussion that's on the issue itself.

Whoever raised the TAG issue, will get live feedback from us, either in our Github issue or in their issues, or in a way that they prefer to receive it.

And if appropriate we'll issue a more formal feedback document.

We haven't really felt the need to do that recently.

We've been more focusing on putting our feedback into our own issues or into other people's Github Issues.

And we found that to be a very effective way of communicating and getting our feedback across.

You can find the current work of the TAG, which includes all the design reviews that we're doing, links to how to work with the TAG, and also, our meetings repo, linked off from https://tag.w3.org.

I'd like to mention the meetings repo for a second.

If you're the kind of person that wants to find out what the TAG is working on, on a weekly basis, you can always go and look at our agendas, which are produced on a weekly basis, usually the week before the TAG meetings are happening.

And those are all posted onto our GitHub, and our meeting minutes are also all posted on to GitHub in markdown format after the meetings occur.

So usually we are compiling all of our minutes into one document, which includes the all the breakouts and the plenary minutes.

And then we are posting that in one place.

So I wanna take a second to talk about Client-side API Design Principles.

This is a document that we have been working on for quite a while.

And, we've just recently put more work into it, so we're very happy to be able to share it with you now.

This is basically a document which rolls up a lot of the work that we've been doing in our API and in our design reviews.

And it brings it into one document.

It's something that we've been working on and adding to for a while, but we've just been doing some rather large pieces of additional work to bring more information and more principles and more, I don't know.

The kind of "wisdom of the TAG" into this document.

It's designed primarily for spec developers.

So it's a document that we wouldn't normally expect web developers to be reading, although we're certainly happy to get their feedback.

But it's more to do with, when you're designing a specification, in particular an API, but it doesn't need to be an API.

We would like people to read this.

And in fact, we ask, when people are submitting a request for review, we asked them, have they read this document?

It's also a place where we collect up good practice that comes up in the context of our design reviews, and it's been gradually taking on principles from other sources.

So what's an example of that?

For instance, you can see right at the bottom of this page, underneath the 1.1, within Client-side API Design Principles, we've actually taken some of the texts to that, about priority of constituencies, which was from the HTML Design Principles document.

And we've brought that over into our TAG design principles.

We thought that was important to have in a more up-to-date refreshed document.

In the process we've also linked through to our Ethical Web Principles document where appropriate.

So where we think there's a principle that we've articulated in this document that is related to, or has underpinnings in the Ethical Principles, we've called that out as well.

So that we can be clear about where we're, why some of these things exist and how they relate to the Ethical Web Principles document, which I'll talk about in a second.

So we've also, as I mentioned, updated the TAG Ethical Web Principles.

So in particular I'd like to point out that each principle now includes individually linkable anchor.

And as I mentioned, we use this document in the context of our design reviews, and we also reference this in our design guidelines document.

The principles that I was talking about.

We've also last year, a little bit earlier last year, but I just wanted to bring it to everybody's attention;

we updated our Security and Privacy Self Review Questionnaire document.

And that was work that Lukasz, who was on the TAG up until late last year, concluded with the PING group, and which we're very happy about actually.

It's a document which really exhaustively, get spec developers to think about all the security and privacy issues that they might have, within any particular specification.

And the idea is, and again, this is something that we ask spec developers who are requesting a design review.

We ask them not only to read this document, but actually to write a response document to us, and leave it somewhere that we can reference and read.

So we found that this has been really useful, we've gotten a lot of good feedback from spec developers that they find this information useful because it helps them to think about privacy and security of their specification.

It helps them to think about those topics which may not be topics which are the closest to their way of thinking, but it helps them to really think about these in a very structured way.

So I encourage you to take a look at this as well.

Finally I just wanted to talk about, we're taking a new approach to cross-repo issues tracking.

So this is largely taking advantage of some work that W3C Team had been doing really great work in my opinion on stitching together, the different issues registries within different specifications development areas that are happening on GitHub.

So in particular there is a concept of horizontal review.

TAG review is definitely part of horizontal review.

And now, within a special horizontal review tracker, that W3C has put together, you can see which issues TAG is keeping an eye on.

This allows us to close our design review issue, so then we can actually close an issue where we feel like we provided the feedback that we wanted to provide.

But we can still keep an eye on open issues, that have been opened up against another specification's issue tracker or issue list.

Just so that we can see, and keep tabs on where our, where our feedback has gone, and whether or not it's being implemented, or how it's being implemented and that kind of thing.

So we can keep track of things like that.

We've been very happy to see that approach come out of the W3C Team.

So anyway, that's about it from me.

I definitely look forward to your questions.

You can get in touch with me at dan@torgo.com or d.appelquist@samsung.com if you want to by email or you can follow us @w3ctag on Twitter, or indeed you can get in touch with me on the new W3C Slack Developer Engagement Slack channel as well.

Anything works, and I'd be happy to answer any questions you have, either online or offline however you want.

So thank you again for your participation in this virtual meeting and for your attention.

And I look forward to seeing you in person in the next Advisory Committee meeting.