Reduce the TAG's design review workload

[jyasskin]

The TAG decided in Edinburgh (2024-11) to focus more on Findings and other architectural leadership documents over design reviews, and primarily use design reviews as input to those documents and to catch significant problems before they're added to the web. While we have focused a bit more on the larger documents, partly by ensuring that PRs against them are prioritized in our weekly meetings, we're not managing to devote large amounts of time to writing. The group's sense is that this is because

1. we're feeling pressure to do the design reviews that we've been assigned and
2. the weekly agenda is a TODO list for everyone, and it contains mostly design reviews.

So we need to reduce the number of design reviews that we accept, in order to make time for other writing.

However, when we look at any particular design review and ask if it's unimportant enough for us to decline it, we almost always decide that it's worth looking at. This is understandable: every part of the platform is important, and we've all learned that when you look at a design or specification in detail, you always find problems. If we decline to review something and then it ships, it's almost certain that we'll later notice a problem that we could have fixed if we got to it in time.

So we need to find a way to decline reviews in a way that doesn't make us feel responsible for the problems that will inevitably slip through.

A constraint on possible solutions

If we start a review and ask the proponents questions to inform us, it's rude to then drop the review with no comments. So we need to decline the reviews early, before starting work on them.

[jyasskin]

A possible solution: Autodecline after a time limit

When a new review comes in, it's up to the TAG in general to volunteer to review it. Everyone should keep an eye on their own workload and only assign themselves when they have time to follow through with a review.

We can schedule meeting time for people to look through the issues, but we shouldn't go through them as a group and pause for a decision on each one. If someone feels strongly that we should pick up a review, but they don't personally have the skills to review it, they need to talk directly to the chairs or to someone with the right skills to convince them to pick it up.

Then, after a certain amount of time (1 month?) we have the github bot decline reviews that didn't get picked up.

[jyasskin]

A possible solution: Prioritize before assignment

Rather than looking at new review requests in isolation when they come in, have some sorting mechanism (GitHub has a Kanban project board that might help) where we are able to look at all open requests. Then we discuss what is most important. Highly prioritized items are assigned.

Importance is assessed as a combination of factors:

• How much effort we think the review might take
• What stage the proposal is at
• The magnitude of the impact on the platform

(This is a practice that lean and agile software development practices advocate for.)

Maintaining a ranked list of review requests might also aid chairs in their setting of agendas.

This might be combined with other solutions; it’s not necessarily going to solve the problem on its own.

A more radical way of thinking of this is to say we should run two week sprints, with concrete assignments only for the next sprint.

[Apologies that I've lost whose suggestion this was; feel free to edit this to take credit.]

[jyasskin]

We discussed this earlier this week, and came to 3 action items:

• Set up the Kanban boards by breakout. <- @martinthomson
  • Done at https://github.com/orgs/w3ctag/projects/6/views/1. Next the breakouts need to claim and prioritize issues.
• Autoclose issues that have never been assigned after 2 months. w3ctagbot#62 <- @jyasskin
• Show how many design reviews each TAG member is assigned w3ctagbot#63 <- @jyasskin

My bits will be done inside https://github.com/w3ctag/w3ctagbot, but after I'm back from vacation the week of July 14.