Jeffrey Yasskin would like Chris Harrelson to review this change authored by Noam Rosenthal.
Add note about TAG reviews that take too long
diff --git a/site/blink/launching-features/index.md b/site/blink/launching-features/index.md
index 7bbc692..a21723e 100644
--- a/site/blink/launching-features/index.md
+++ b/site/blink/launching-features/index.md
@@ -314,6 +314,9 @@
this at least a month ahead of sending an Intent to Ship, to give the TAG
sufficient time for meaningful feedback.
+ Note that if the TAG review takes long and the design is being matured elsewhere, to the point where a TAG review would no longer be helpful,
+ it's best to notify the TAG team so that they can close the issue and prioritze other issues.
+
#### Step 5 (Optional): Origin Trial {:#origin-trials}
If you want to gather data on the usability of your feature that an [Origin
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hi API owners. This came up around https://github.com/w3ctag/design-reviews/issues/886#issuecomment-1953174126, where the WHATWG discussion had come to consensus in the 6 months since the TAG review was filed, and that discussion already covered the concerns the TAG raised. There were some improvements our team could have made to their explainer to prevent the TAG's concerns, which this change doesn't intend to cover.
This change is about how and when to tell the TAG that a design is frozen, and so it's not worth their time to review it any more. I'm not sure Noam's change or my suggestions convey that exactly right, and I'd love to hear more opinions.
Note that if the TAG review takes long and the design is being matured elsewhere, to the point where a TAG review would no longer be helpful,
I think we should be more specific about what indicates that a TAG review would no longer be helpful. Perhaps:
```suggestion
Note that if the TAG takes several months to review the feature,
and during that time the implementations and relevant standards
bodies find consensus on the feature, the TAG's review might not
be able to influence the design anymore. If that happens,
```
If the TAG has commented on your review, and the state of the review is anything
other than [`Resolution:
satisfied`](https://github.com/w3ctag/design-reviews/issues?q=is%3Aissue+label%3A%22Resolution%3A+satisfied%22),
the API Owners should be able to see evidence that you've seriously and
comprehensively engaged with their comments, and tried to resolve any concerns.
We might also want to say something here about "if the TAG has _not_ commented"...
```suggestion
If the TAG has commented on your review, and the state of the review is anything
other than [`Resolution:
satisfied`](https://github.com/w3ctag/design-reviews/issues?q=is%3Aissue+label%3A%22Resolution%3A+satisfied%22),
the API Owners should be able to see evidence that you've seriously and
comprehensively engaged with their comments, and tried to resolve any concerns.
If the TAG has _not_ commented, then after your I2S is approved, it's courteous
to post to the review saying that Chromium considers the feature stable, and
any future suggestions will need to come with stronger justifications.
```
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Note that if the TAG review takes long and the design is being matured elsewhere, to the point where a TAG review would no longer be helpful,
I think we should be more specific about what indicates that a TAG review would no longer be helpful. Perhaps:
```suggestion
Note that if the TAG takes several months to review the feature,
and during that time the implementations and relevant standards
bodies find consensus on the feature, the TAG's review might not
be able to influence the design anymore. If that happens,
```
Fix applied.
If the TAG has commented on your review, and the state of the review is anything
other than [`Resolution:
satisfied`](https://github.com/w3ctag/design-reviews/issues?q=is%3Aissue+label%3A%22Resolution%3A+satisfied%22),
the API Owners should be able to see evidence that you've seriously and
comprehensively engaged with their comments, and tried to resolve any concerns.
We might also want to say something here about "if the TAG has _not_ commented"...
```suggestion
If the TAG has commented on your review, and the state of the review is anything
other than [`Resolution:
satisfied`](https://github.com/w3ctag/design-reviews/issues?q=is%3Aissue+label%3A%22Resolution%3A+satisfied%22),
the API Owners should be able to see evidence that you've seriously and
comprehensively engaged with their comments, and tried to resolve any concerns.
If the TAG has _not_ commented, then after your I2S is approved, it's courteous
to post to the review saying that Chromium considers the feature stable, and
any future suggestions will need to come with stronger justifications.
```
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
it's best to notify the TAG team so that they can close the issue and prioritze other issues.
Drop the word "team", and fix spelling of "prioritize".
```suggestion
it's best to notify the TAG so that they can close the issue and prioritize other issues.
```
If the TAG has commented on your review, and the state of the review is anything
other than [`Resolution:
satisfied`](https://github.com/w3ctag/design-reviews/issues?q=is%3Aissue+label%3A%22Resolution%3A+satisfied%22),
the API Owners should be able to see evidence that you've seriously and
comprehensively engaged with their comments, and tried to resolve any concerns.
We might also want to say something here about "if the TAG has _not_ commented"...
```suggestion
If the TAG has commented on your review, and the state of the review is anything
other than [`Resolution:
satisfied`](https://github.com/w3ctag/design-reviews/issues?q=is%3Aissue+label%3A%22Resolution%3A+satisfied%22),
the API Owners should be able to see evidence that you've seriously and
comprehensively engaged with their comments, and tried to resolve any concerns.
If the TAG has _not_ commented, then after your I2S is approved, it's courteous
to post to the review saying that Chromium considers the feature stable, and
any future suggestions will need to come with stronger justifications.
```
I think the last phrase in this suggestion might be a bit awkward (in that it seems to be telling the TAG what to do rather than telling them what the Chromium project will do). Perhaps instead of "any future suggestions will need to come with stronger justifications" maybe something like "future proposals for changes will be weighed against the compatibility risk of changing a shipping feature".
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
If the TAG has commented on your review, and the state of the review is anything
other than [`Resolution:
satisfied`](https://github.com/w3ctag/design-reviews/issues?q=is%3Aissue+label%3A%22Resolution%3A+satisfied%22),
the API Owners should be able to see evidence that you've seriously and
comprehensively engaged with their comments, and tried to resolve any concerns.
David BaronWe might also want to say something here about "if the TAG has _not_ commented"...
```suggestion
If the TAG has commented on your review, and the state of the review is anything
other than [`Resolution:
satisfied`](https://github.com/w3ctag/design-reviews/issues?q=is%3Aissue+label%3A%22Resolution%3A+satisfied%22),
the API Owners should be able to see evidence that you've seriously and
comprehensively engaged with their comments, and tried to resolve any concerns.
If the TAG has _not_ commented, then after your I2S is approved, it's courteous
to post to the review saying that Chromium considers the feature stable, and
any future suggestions will need to come with stronger justifications.
```
I think the last phrase in this suggestion might be a bit awkward (in that it seems to be telling the TAG what to do rather than telling them what the Chromium project will do). Perhaps instead of "any future suggestions will need to come with stronger justifications" maybe something like "future proposals for changes will be weighed against the compatibility risk of changing a shipping feature".
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
This LGTM, incorporating dbaron's suggestions.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Applied comments. @jyas...@google.com do you mind taking a last look before I CQ?
it's best to notify the TAG team so that they can close the issue and prioritze other issues.
Drop the word "team", and fix spelling of "prioritize".
```suggestion
it's best to notify the TAG so that they can close the issue and prioritize other issues.
```
Done
If the TAG has commented on your review, and the state of the review is anything
other than [`Resolution:
satisfied`](https://github.com/w3ctag/design-reviews/issues?q=is%3Aissue+label%3A%22Resolution%3A+satisfied%22),
the API Owners should be able to see evidence that you've seriously and
comprehensively engaged with their comments, and tried to resolve any concerns.
David BaronWe might also want to say something here about "if the TAG has _not_ commented"...
```suggestion
If the TAG has commented on your review, and the state of the review is anything
other than [`Resolution:
satisfied`](https://github.com/w3ctag/design-reviews/issues?q=is%3Aissue+label%3A%22Resolution%3A+satisfied%22),
the API Owners should be able to see evidence that you've seriously and
comprehensively engaged with their comments, and tried to resolve any concerns.
If the TAG has _not_ commented, then after your I2S is approved, it's courteous
to post to the review saying that Chromium considers the feature stable, and
any future suggestions will need to come with stronger justifications.
```
Jeffrey YasskinI think the last phrase in this suggestion might be a bit awkward (in that it seems to be telling the TAG what to do rather than telling them what the Chromium project will do). Perhaps instead of "any future suggestions will need to come with stronger justifications" maybe something like "future proposals for changes will be weighed against the compatibility risk of changing a shipping feature".
That sounds better to me too.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Note that if the TAG review takes long and the design is being matured elsewhere, to the point where a TAG review would no longer be helpful,
Noam RosenthalI think we should be more specific about what indicates that a TAG review would no longer be helpful. Perhaps:
```suggestion
Note that if the TAG takes several months to review the feature,
and during that time the implementations and relevant standards
bodies find consensus on the feature, the TAG's review might not
be able to influence the design anymore. If that happens,
```
Fix applied.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Note that if the TAG review takes long and the design is being matured elsewhere, to the point where a TAG review would no longer be helpful,
Noam RosenthalI think we should be more specific about what indicates that a TAG review would no longer be helpful. Perhaps:
```suggestion
Note that if the TAG takes several months to review the feature,
and during that time the implementations and relevant standards
bodies find consensus on the feature, the TAG's review might not
be able to influence the design anymore. If that happens,
```
Jeffrey YasskinFix applied.
This got lost again in patchset 4. 🙃
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Commit-Queue | +2 |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Add note about TAG reviews that take too long
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |