Clarification on TAG Reviews

[Nicolás Peña]

Hi Blink API OWNERS,

I'd like some clarification on Alex Russell's comment on User Timing L3 and in general the process of TAG reviews. I don't agree with requiring TAG review for every IDL change. I have thus far submitted two reviews, in November, and they have not been completed yet. A quick look at the list of open issues shows that these are not rare exceptions. Based on the updates on the bug it seems that updates function on the basis of calls where APIs are discussed, and calls may or may not have enough time allotted to discuss all of the reviews. This is probably because there are too many APIs that need to be reviewed, and not enough bandwidth from the group to execute all of those reviews promptly.

Given the slow responsiveness of reviews, I tend to view them as only useful for massive changes to existing APIs or for completely new APIs. I don't think that it would be reasonable to wait more than 5 months for a TAG review of, say, UserTiming L3. Ideally, the working group will have people with enough knowledge of WebIDL to help prevent mistakes like the ones that happened. In this case such review failed to see some problems, but I don't think that implies that everything should go through the small set of people that manage TAG reviews. What are the guidelines for assessing whether TAG review is needed, given that these reviews are taking so long to be completed?

[Chris Harrelson]

Hi Nicolás,

We are definitely aware of the fact that TAG reviews sometimes take a long time. In our weekly review meetings, we check in on all of the currently outstanding TAG reviews, and when needed take actions, including pinging TAG review members to expedite reviews, or if the delay has been unreasonable, and we feel risk is limited, approving the intent. We also don't block on TAG reviews being "closed".

Regarding the two reviews you filed, I see that there was substantive feedback on both. Though it's also true that the TAG did not actually close out the issues. I think this is an area where the TAG can do better. +aboxhall for that feedback.

The intent process also recommends filing TAG reviews at the intent-to-implement phase, in order to avoid extra delays and get feedback earlier.

Thanks,

Chris

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAATDimfW-AOU8hE7Ekh-k8-xCoWhWB4%2B9EzHwBzwnm0NdpK%3Dg%40mail.gmail.com.

[Yoav Weiss]

I think that regardless of how long TAG reviews take, it's important to set a clear bar of what should go through TAG review vs. what shouldn't.

Currently, I see many claiming that a TAG review is not needed as their feature is a small addition to an existing one, but we don't have a clear bar as to what can be considered "small", so it's up to the API owners judgement. Having a clearer bar would be better to set expectations as well as help the owners in making these calls.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZvTp1Wn_m2oMM8f-29WbQUfHobFObVWtAQamK36pey%2Bhw%40mail.gmail.com.

[Alex Russell]

"small" changes have frequently hidden large mistakes or discontinuities in the design space. My preference is that somebody at least smell-test an exception with a current or former TAG member.

On Tuesday, May 7, 2019 at 8:45:46 AM UTC-7, Yoav Weiss wrote:

I think that regardless of how long TAG reviews take, it's important to set a clear bar of what should go through TAG review vs. what shouldn't.

Currently, I see many claiming that a TAG review is not needed as their feature is a small addition to an existing one, but we don't have a clear bar as to what can be considered "small", so it's up to the API owners judgement. Having a clearer bar would be better to set expectations as well as help the owners in making these calls.

On Fri, May 3, 2019 at 2:05 PM Chris Harrelson <chri...@chromium.org> wrote:

Hi Nicolás,

We are definitely aware of the fact that TAG reviews sometimes take a long time. In our weekly review meetings, we check in on all of the currently outstanding TAG reviews, and when needed take actions, including pinging TAG review members to expedite reviews, or if the delay has been unreasonable, and we feel risk is limited, approving the intent. We also don't block on TAG reviews being "closed".

Regarding the two reviews you filed, I see that there was substantive feedback on both. Though it's also true that the TAG did not actually close out the issues. I think this is an area where the TAG can do better. +aboxhall for that feedback.

The intent process also recommends filing TAG reviews at the intent-to-implement phase, in order to avoid extra delays and get feedback earlier.

Thanks,

Chris

On Thu, May 2, 2019 at 1:31 PM Nicolás Peña <n...@chromium.org> wrote:

Hi Blink API OWNERS,

I'd like some clarification on Alex Russell's comment on User Timing L3 and in general the process of TAG reviews. I don't agree with requiring TAG review for every IDL change. I have thus far submitted two reviews, in November, and they have not been completed yet. A quick look at the list of open issues shows that these are not rare exceptions. Based on the updates on the bug it seems that updates function on the basis of calls where APIs are discussed, and calls may or may not have enough time allotted to discuss all of the reviews. This is probably because there are too many APIs that need to be reviewed, and not enough bandwidth from the group to execute all of those reviews promptly.

Given the slow responsiveness of reviews, I tend to view them as only useful for massive changes to existing APIs or for completely new APIs. I don't think that it would be reasonable to wait more than 5 months for a TAG review of, say, UserTiming L3. Ideally, the working group will have people with enough knowledge of WebIDL to help prevent mistakes like the ones that happened. In this case such review failed to see some problems, but I don't think that implies that everything should go through the small set of people that manage TAG reviews. What are the guidelines for assessing whether TAG review is needed, given that these reviews are taking so long to be completed?

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.

To post to this group, send email to blink-api-ow...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAATDimfW-AOU8hE7Ekh-k8-xCoWhWB4%2B9EzHwBzwnm0NdpK%3Dg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.

[Alice Boxhall]

Chris-in-absentia, thanks for adding me. 

Nicolás, I'm sorry we've dropped the ball on your reviews; I'll see if I can get to the bottom of that so we can either close them out or have a meaningful update in the next couple of weeks.

I think there is definitely a conversation to be had about how best to manage the interaction between TAG and the blink intent process. As you would have noticed, we on the TAG are somewhat drowning in review requests from blink engineers at the moment. 

In some ways this is a great problem to have; as a blink engineer I'm happy to see it because it means the team is making a lot of progress, and as a TAG member it's useful to have a good overview of where the platform is headed and to potentially be able to keep things heading in a good direction via facilitating communication, harmonising related things with one another, pushing back on questionable design choices etc.

However, obviously it's currently not a realistic workload for us, which is leading to bad experiences for requestors like this one, which quite reasonably leads to questioning the value of this process.

I can certainly see how it would seem reasonable to bypass the TAG review process for "smaller" changes, however as Alex and Yoav have pointed out, it's never really clear what constitutes a "small" change.

The current process is very lenient about what documentation is required; in particular, it suggests but does not require an explainer with a clear problem statement and example code. I have raised the idea of having a stronger requirement for a clear, concise explanation of:

- the problem facing the end user (preferably) or authors, 

- the proposed solution, and 

- worked code examples of how the proposed solution solves the stated problem. 

Many requests have minimal context and make the TAG members do extra work to figure these things out, leading to even longer waits for everyone.

While this would require more work up-front from requestors, I think we have a responsibility to the web platform to carefully consider the things we're shipping, and having the TAG weigh in has often picked up issues that we haven't considered.

On the TAG side, we are also trying to work on processes to get through the backlog more quickly by not requiring a quorum of TAG members to look at each proposal.  

For anyone with an open review which hasn't yet had a comment, adding a brief explainer if you don't have one already would be very much appreciated and help us work through things quicker.

Thanks,

Alice

On Wed, May 8, 2019 at 2:25 AM Alex Russell <sligh...@google.com> wrote:

"small" changes have frequently hidden large mistakes or discontinuities in the design space. My preference is that somebody at least smell-test an exception with a current or former TAG member.

On Tuesday, May 7, 2019 at 8:45:46 AM UTC-7, Yoav Weiss wrote:

I think that regardless of how long TAG reviews take, it's important to set a clear bar of what should go through TAG review vs. what shouldn't.

Currently, I see many claiming that a TAG review is not needed as their feature is a small addition to an existing one, but we don't have a clear bar as to what can be considered "small", so it's up to the API owners judgement. Having a clearer bar would be better to set expectations as well as help the owners in making these calls.

On Fri, May 3, 2019 at 2:05 PM Chris Harrelson <chri...@chromium.org> wrote:

Hi Nicolás,

We are definitely aware of the fact that TAG reviews sometimes take a long time. In our weekly review meetings, we check in on all of the currently outstanding TAG reviews, and when needed take actions, including pinging TAG review members to expedite reviews, or if the delay has been unreasonable, and we feel risk is limited, approving the intent. We also don't block on TAG reviews being "closed".

Regarding the two reviews you filed, I see that there was substantive feedback on both. Though it's also true that the TAG did not actually close out the issues. I think this is an area where the TAG can do better. +aboxhall for that feedback.

The intent process also recommends filing TAG reviews at the intent-to-implement phase, in order to avoid extra delays and get feedback earlier.

Thanks,

Chris

On Thu, May 2, 2019 at 1:31 PM Nicolás Peña <n...@chromium.org> wrote:

Hi Blink API OWNERS,

I'd like some clarification on Alex Russell's comment on User Timing L3 and in general the process of TAG reviews. I don't agree with requiring TAG review for every IDL change. I have thus far submitted two reviews, in November, and they have not been completed yet. A quick look at the list of open issues shows that these are not rare exceptions. Based on the updates on the bug it seems that updates function on the basis of calls where APIs are discussed, and calls may or may not have enough time allotted to discuss all of the reviews. This is probably because there are too many APIs that need to be reviewed, and not enough bandwidth from the group to execute all of those reviews promptly.

Given the slow responsiveness of reviews, I tend to view them as only useful for massive changes to existing APIs or for completely new APIs. I don't think that it would be reasonable to wait more than 5 months for a TAG review of, say, UserTiming L3. Ideally, the working group will have people with enough knowledge of WebIDL to help prevent mistakes like the ones that happened. In this case such review failed to see some problems, but I don't think that implies that everything should go through the small set of people that manage TAG reviews. What are the guidelines for assessing whether TAG review is needed, given that these reviews are taking so long to be completed?

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.

To post to this group, send email to blink-api-ow...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAATDimfW-AOU8hE7Ekh-k8-xCoWhWB4%2B9EzHwBzwnm0NdpK%3Dg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.

[Yoav Weiss]

Thanks Alice! :)

I read that as "no change is too small to go through the TAG review process".

If that's indeed our stance, it might be worthwhile to clarify that in our "intent" documents and on chromestatus.

/cc +Johnny Stenback 

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

[Nicolás Peña]

I'm happy to submit TAG reviews always as long as there is a reasonable review latency, which has not been the case in my experience. If the plan is to keep the TAG process as-is and require TAG reviews always, then I'd expect most of them to not have been properly reviewed by the time Blink engineers send their Intent to Ship. This kind of defeats the purpose of requesting review in the first place.