PSA: TAG Reviews Are Required

[Alex Russell]

Hey All,

I've seen quite a lot of intents coming through suggesting that changes are "small" and therefore don't require review by a broader audience. This is a fast way to ensure that your feature or launch is delayed and that the OWNERS scrutinize your launch closely to look for other potential cut corners.

Our process currently has no carve-out for non-filing for reviews. There have been one-off cases where, for example, the TAG has been slow to respond and the OWNERS have made exceptions to ensure that folks who have done their due diligence are not overly impeded. We're also looking at a way to perhaps skip this loop based on some sort of firmer criteria (although those are still in discussion), but until the process changes formally, know that no exemption exists, regardless of feature size.

Regards

[Anders Hartvoll Ruud]

Just to clarify: this applies to any Intent to Ship, regardless of what it is?

"Regardless of feature size" made it sound like it only applies to new features.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9faba33e-8503-4600-910d-caa72c20be83n%40chromium.org.

[Vladimir Levin]

Also to clarify: this applies specifically to intent to *ship*, right? If it's an intent to prototype for a new feature, is filing a TAG review mandatory?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKFBnUqka9zyAWt9eQ0WSd9TpeVObOTgq3Bi8ZWVjUe3ocekfA%40mail.gmail.com.

[Chris Harrelson]

Intent to ship is where we will definitely enforce the policy. At earlier phases we'll remind you and warn you about filing one earlier rather than later.

Regarding which situations can go without a TAG review: the API owners discussed this a few times and it's hard to come up with a simple characterization of risk for new features. We can imagine cases where we'd be willing to bend a bit, but it's hard to provide reliable guidance for corner cases. We did decide that the following cases don't need a TAG review:

1. Shipping a new API or augmentation of an API, or changing an API to match a spec, that is (a) already specified and accepted by the relevant standardization body, and (b) has already shipped in at least one other browser.

2. Removing a feature.

3. JavaScript/WebAssembly language features that have reached the appropriate TC39 standardization level that implies broad review and agreement.

There will be other cases where we'd allow skipping a TAG review, but again it's hard to write it down in a simple rule. For example, the recent intent about shipping a new stub interface class in WebXR that doesn't have any new functionality implied in it seems more than safe enough, so I am ok skipping a TAG review for it specifically. If anyone has good ideas for additional rules or categories that can increase the clarity of the process, we're all ears.

Chris

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MTc2EYT6%2BmGcYrtKhbH-5UFFy%2BGc0_CdmePbUKyGpBTw%40mail.gmail.com.

[David Benjamin]

How would you all like low-level network protocol changes to be handled? I'm thinking about things like new versions or extensions to TLS. A lot of those changes live entirely on the IETF side of things, without any W3C/WHATWG bits.

The changes are, strictly speaking, visible to the overall web platform, so most of the Blink process makes sense. But they don't affect any APIs per se and sometimes not even HTTP, so it's a slightly different audience (more server operators and developers of server software) and a slightly different ecosystem. It's also a somewhat different standardization process.

I've typically marked such intents as not needing TAG review (e.g. TLS 1.3), on the assumption that this sort of thing was outside of the TAG's scope. Is that right, or should those also request TAG reviews? (I'm fine either way. Just wanted to check what you all prefer here.)

David

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-1KMKx7B%3Dk5y1Z0KHj_yzLr3%3D9Sw9nd5yJuDQXExAJjQ%40mail.gmail.com.

[Chris Harrelson]

On Fri, Nov 13, 2020 at 10:31 AM David Benjamin <davi...@chromium.org> wrote:

How would you all like low-level network protocol changes to be handled? I'm thinking about things like new versions or extensions to TLS. A lot of those changes live entirely on the IETF side of things, without any W3C/WHATWG bits.

The changes are, strictly speaking, visible to the overall web platform, so most of the Blink process makes sense. But they don't affect any APIs per se and sometimes not even HTTP, so it's a slightly different audience (more server operators and developers of server software) and a slightly different ecosystem. It's also a somewhat different standardization process.

I've typically marked such intents as not needing TAG review (e.g. TLS 1.3), on the assumption that this sort of thing was outside of the TAG's scope. Is that right, or should those also request TAG reviews? (I'm fine either way. Just wanted to check what you all prefer here.)

Hi David, thanks for asking.

I think these should go through the TAG, at least for now. These protocols are important to the web and probably have interactions with other parts of the platform that justify wider review.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAF8qwaC5uEPQ54sLxMBS85tBRCFwbGqdQLW%2BURYMC1oU_caoNA%40mail.gmail.com.

[Shu-yu Guo]

To clarify the JS/Wasm position a bit, occasionally there *are* features in TC39 (not sure about the wasm CG) that have significant interaction with the web platform, e.g. WeakRefs. Those features should and do require TAG review, and currently the more web-exposed folks in TC39 (myself, Dan Ehrenberg) have been making sure champions of that kind of proposals request TAG reviews. Since the bulk of JS features do not have such interaction, I very much welcome the default of being not needing TAG reviews. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-1KMKx7B%3Dk5y1Z0KHj_yzLr3%3D9Sw9nd5yJuDQXExAJjQ%40mail.gmail.com.

[Alex Russell]

Great questions! Inline:

On Friday, November 13, 2020 at 10:31:34 AM UTC-8 David Benjamin wrote:

How would you all like low-level network protocol changes to be handled? I'm thinking about things like new versions or extensions to TLS. A lot of those changes live entirely on the IETF side of things, without any W3C/WHATWG bits.

The TAG has a liaison with IETF with.

 

The changes are, strictly speaking, visible to the overall web platform, so most of the Blink process makes sense. But they don't affect any APIs per se and sometimes not even HTTP, so it's a slightly different audience (more server operators and developers of server software) and a slightly different ecosystem. It's also a somewhat different standardization process.

We put many features through the TAG that do not follow traditional W3C process, including some developed at WHATWG and IETF.

 

I've typically marked such intents as not needing TAG review (e.g. TLS 1.3), on the assumption that this sort of thing was outside of the TAG's scope. Is that right, or should those also request TAG reviews? (I'm fine either way. Just wanted to check what you all prefer here.)

Given that the goal here is to file very early, a lot of IETF stuff winds up being FYI-ish, so I recommend doing it at I2P stage (as the process currently recommends). That will give TAG enough time to say "not our bag" if that's, in case, the situation.

Regards

[Chris Harrelson]

On Fri, Nov 13, 2020 at 12:50 PM Shu-yu Guo <s...@chromium.org> wrote:

To clarify the JS/Wasm position a bit, occasionally there *are* features in TC39 (not sure about the wasm CG) that have significant interaction with the web platform, e.g. WeakRefs. Those features should and do require TAG review, and currently the more web-exposed folks in TC39 (myself, Dan Ehrenberg) have been making sure champions of that kind of proposals request TAG reviews. Since the bulk of JS features do not have such interaction, I very much welcome the default of being not needing TAG reviews. 

Good point. default not-TAG as I mentioned, but TAG review for certain cases like WeakRefs.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN-e9e8WPWv1T6HkRfErkuSa4iXkewAQRXET20WjVcgfGr-1Zw%40mail.gmail.com.