Recent changes to the launch process

[Jeffrey Yasskin]

I made a few recent changes to the launch process document, thinking that we'd either already agreed on the direction or that they'd get cc'ed to the right discussion group for review, but the discussion on the Intent to Experiment: ServiceWorkerBypassFetchHandlerForMainResources thread makes me think that didn't happen. It sounds like Mike's going to make the cc'ing happen in the future, but to make sure none of the changes slip past actual review:

https://chromium-review.googlesource.com/c/website/+/4162680: Suggest starting spec-writing around the beginning of origin trials. I also renamed step 4 to "Widen review" to avoid confusion between "evaluate readiness" and "prepare".

https://chromium-review.googlesource.com/c/website/+/4162682: Require the explainer move into a CG by the "widen review" step, which is before OT. This is the change that I referred to in the above I2E thread. I don't think this change implies that a spec needs to be written before the OT starts, but if it does, we should fix that.

https://chromium-review.googlesource.com/c/website/+/4179313: Explain what y'all want to see if the TAG isn't satisfied with a feature.

https://chromium-review.googlesource.com/c/website/+/4179317: Simplify and add links to the Incubation instructions. This shouldn't have changed any meanings.

https://chromium-review.googlesource.com/c/website/+/4209834: Ask feature authors to propose, before shipping, that a WG take up new features. This doesn't require that a WG _adopt_ before we ship. I'd expected this one to be the most contentious.

Let me know if any of these need actual discussion.

Thanks,

Jeffrey

[Yoav Weiss]

On Wed, Feb 22, 2023 at 11:58 PM 'Jeffrey Yasskin' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

I made a few recent changes to the launch process document, thinking that we'd either already agreed on the direction or that they'd get cc'ed to the right discussion group for review, but the discussion on the Intent to Experiment: ServiceWorkerBypassFetchHandlerForMainResources thread makes me think that didn't happen. It sounds like Mike's going to make the cc'ing happen in the future, but to make sure none of the changes slip past actual review:

https://chromium-review.googlesource.com/c/website/+/4162680: Suggest starting spec-writing around the beginning of origin trials. I also renamed step 4 to "Widen review" to avoid confusion between "evaluate readiness" and "prepare".

https://chromium-review.googlesource.com/c/website/+/4162682: Require the explainer move into a CG by the "widen review" step, which is before OT. This is the change that I referred to in the above I2E thread. I don't think this change implies that a spec needs to be written before the OT starts, but if it does, we should fix that.

As I mentioned in the other thread, I don't believe we have had broader group discussion around that particular point. We previously agreed that specs need to be in an incubation venue for OT extensions beyond 6 milestones, but not necessarily to enter the OT stage.

I think it might make sense, in cases where there's an actual spec at OT time. But that may not always be the case.

 

https://chromium-review.googlesource.com/c/website/+/4179313: Explain what y'all want to see if the TAG isn't satisfied with a feature.

https://chromium-review.googlesource.com/c/website/+/4179317: Simplify and add links to the Incubation instructions. This shouldn't have changed any meanings.

https://chromium-review.googlesource.com/c/website/+/4209834: Ask feature authors to propose, before shipping, that a WG take up new features. This doesn't require that a WG _adopt_ before we ship. I'd expected this one to be the most contentious.

That indeed seems very tricky. Do we expect feature owners to open issues proposing a WG migration? Talk to the chairs?

Ask for a CfC?

Let me know if any of these need actual discussion.

Thanks,

Jeffrey

--
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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANh-dXkFxR5zTnqN%3DYmWNJQG7du4LeaWWj4onerCrHwYW2Yxqw%40mail.gmail.com.

[Jeffrey Yasskin]

On Wed, Feb 22, 2023 at 9:55 PM Yoav Weiss <yoav...@google.com> wrote:

On Wed, Feb 22, 2023 at 11:58 PM 'Jeffrey Yasskin' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

https://chromium-review.googlesource.com/c/website/+/4162682: Require the explainer move into a CG by the "widen review" step, which is before OT. This is the change that I referred to in the above I2E thread. I don't think this change implies that a spec needs to be written before the OT starts, but if it does, we should fix that.

As I mentioned in the other thread, I don't believe we have had broader group discussion around that particular point. We previously agreed that specs need to be in an incubation venue for OT extensions beyond 6 milestones, but not necessarily to enter the OT stage.

I think it might make sense, in cases where there's an actual spec at OT time. But that may not always be the case.

So, to start that group discussion: Apple has complained in the past when we ask them for comments on an explainer that's in a personal repo. I think that's reasonable, since the IP grants aren't as clear in a personal repo as they would be in an incubation venue like a CG.

Now, maybe we're not asking Apple for feedback until we have a spec, so we wouldn't have concrete problems with getting feedback on the OT. It's true that the web developers who interact with OTs tend to be less worried about IP issues. But 1) maybe Chromium should be more worried about getting contributions on personal repos that aren't covered by a CLA, and 2) we shouldn't impose IP risks on web developers even if those developers aren't aware of the risks.

If it were expensive to move to a CG, I wouldn't push it at this stage, but the WICG only requires one of the potential OT adopters to say that they're interested in the feature. That seems like a low enough cost that we can ask feature owners to pay it before their OT. There's also no reason you need a spec in order to move to a CG; the WICG adopts explainers all the time.

https://chromium-review.googlesource.com/c/website/+/4209834: Ask feature authors to propose, before shipping, that a WG take up new features. This doesn't require that a WG _adopt_ before we ship. I'd expected this one to be the most contentious.

That indeed seems very tricky. Do we expect feature owners to open issues proposing a WG migration? Talk to the chairs?

Ask for a CfC?

Any of those are acceptable; it just needs to be a clear public statement that we think the incubation is done and ready to move onto the standards track. Mozilla has expressed frustration that we don't do this reliably, which causes some of our finished incubations to get "lost" outside of the standards process even though they have widespread support. @Chris Wilson might add some details once he's back from vacation. This isn't something I think feature owners will have the expertise to do on their own, so https://www.chromium.org/blink/launching-features/#new-feature-prepare-to-ship says to ask your spec mentor for help, and I'll be sending a follow-up change to https://chromium-review.googlesource.com/c/website/+/4233971 to tell spec mentors to ask Chris or me for help.

Jeffrey

[Rick Byers]

On Thu, Feb 23, 2023 at 3:03 PM 'Jeffrey Yasskin' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

On Wed, Feb 22, 2023 at 9:55 PM Yoav Weiss <yoav...@google.com> wrote:

On Wed, Feb 22, 2023 at 11:58 PM 'Jeffrey Yasskin' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

https://chromium-review.googlesource.com/c/website/+/4162682: Require the explainer move into a CG by the "widen review" step, which is before OT. This is the change that I referred to in the above I2E thread. I don't think this change implies that a spec needs to be written before the OT starts, but if it does, we should fix that.

As I mentioned in the other thread, I don't believe we have had broader group discussion around that particular point. We previously agreed that specs need to be in an incubation venue for OT extensions beyond 6 milestones, but not necessarily to enter the OT stage.

I think it might make sense, in cases where there's an actual spec at OT time. But that may not always be the case.

So, to start that group discussion: Apple has complained in the past when we ask them for comments on an explainer that's in a personal repo. I think that's reasonable, since the IP grants aren't as clear in a personal repo as they would be in an incubation venue like a CG.

Now, maybe we're not asking Apple for feedback until we have a spec, so we wouldn't have concrete problems with getting feedback on the OT. It's true that the web developers who interact with OTs tend to be less worried about IP issues. But 1) maybe Chromium should be more worried about getting contributions on personal repos that aren't covered by a CLA, and 2) we shouldn't impose IP risks on web developers even if those developers aren't aware of the risks.

If it were expensive to move to a CG, I wouldn't push it at this stage, but the WICG only requires one of the potential OT adopters to say that they're interested in the feature. That seems like a low enough cost that we can ask feature owners to pay it before their OT. There's also no reason you need a spec in order to move to a CG; the WICG adopts explainers all the time.

This seems like reasonable justification and a reasonable bar to me. As long as we have a good venue (like WICG in it's current form) where a single implementer and single customer can collaborate on a design with low overhead, then I'm supportive of this.

https://chromium-review.googlesource.com/c/website/+/4209834: Ask feature authors to propose, before shipping, that a WG take up new features. This doesn't require that a WG _adopt_ before we ship. I'd expected this one to be the most contentious.

That indeed seems very tricky. Do we expect feature owners to open issues proposing a WG migration? Talk to the chairs?

Ask for a CfC?

Any of those are acceptable; it just needs to be a clear public statement that we think the incubation is done and ready to move onto the standards track. Mozilla has expressed frustration that we don't do this reliably, which causes some of our finished incubations to get "lost" outside of the standards process even though they have widespread support. @Chris Wilson might add some details once he's back from vacation. This isn't something I think feature owners will have the expertise to do on their own, so https://www.chromium.org/blink/launching-features/#new-feature-prepare-to-ship says to ask your spec mentor for help, and I'll be sending a follow-up change to https://chromium-review.googlesource.com/c/website/+/4233971 to tell spec mentors to ask Chris or me for help.

+1 that reducing the risk of incubations getting "lost" is a good thing for us to be doing. I think just filing an issue for some group (with help of mentors) is a very reasonable bar.

Perhaps we should articulate the principle somewhere that we want to go out of our way to foster collaboration but also steadfastly refuse to allow ourselves to be blocked by lack of interest or priority?

Jeffrey

--
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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANh-dX%3D3jaCa7M1zv9vLTdFVyG6iUXFX7%2BPym7BaAaFNO%2B7ZrA%40mail.gmail.com.

[Yoav Weiss]

On Fri, Feb 24, 2023 at 3:07 AM Rick Byers <rby...@chromium.org> wrote:

On Thu, Feb 23, 2023 at 3:03 PM 'Jeffrey Yasskin' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

On Wed, Feb 22, 2023 at 9:55 PM Yoav Weiss <yoav...@google.com> wrote:

On Wed, Feb 22, 2023 at 11:58 PM 'Jeffrey Yasskin' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

https://chromium-review.googlesource.com/c/website/+/4162682: Require the explainer move into a CG by the "widen review" step, which is before OT. This is the change that I referred to in the above I2E thread. I don't think this change implies that a spec needs to be written before the OT starts, but if it does, we should fix that.

As I mentioned in the other thread, I don't believe we have had broader group discussion around that particular point. We previously agreed that specs need to be in an incubation venue for OT extensions beyond 6 milestones, but not necessarily to enter the OT stage.

I think it might make sense, in cases where there's an actual spec at OT time. But that may not always be the case.

So, to start that group discussion: Apple has complained in the past when we ask them for comments on an explainer that's in a personal repo. I think that's reasonable, since the IP grants aren't as clear in a personal repo as they would be in an incubation venue like a CG.

Now, maybe we're not asking Apple for feedback until we have a spec, so we wouldn't have concrete problems with getting feedback on the OT. It's true that the web developers who interact with OTs tend to be less worried about IP issues. But 1) maybe Chromium should be more worried about getting contributions on personal repos that aren't covered by a CLA, and 2) we shouldn't impose IP risks on web developers even if those developers aren't aware of the risks.

If it were expensive to move to a CG, I wouldn't push it at this stage, but the WICG only requires one of the potential OT adopters to say that they're interested in the feature. That seems like a low enough cost that we can ask feature owners to pay it before their OT. There's also no reason you need a spec in order to move to a CG; the WICG adopts explainers all the time.

This seems like reasonable justification and a reasonable bar to me. As long as we have a good venue (like WICG in it's current form) where a single implementer and single customer can collaborate on a design with low overhead, then I'm supportive of this.

Same here, at least for most OTs! Thanks for outlining the reasoning here, Jeffrey! :)

There's a small number of OTs which don't require vendor positions (e.g. we just want to try something out to measure its performance, etc. but with collaborating partners). I think it's fine for those (rare) cases to ask for an exception.

 

https://chromium-review.googlesource.com/c/website/+/4209834: Ask feature authors to propose, before shipping, that a WG take up new features. This doesn't require that a WG _adopt_ before we ship. I'd expected this one to be the most contentious.

That indeed seems very tricky. Do we expect feature owners to open issues proposing a WG migration? Talk to the chairs?

Ask for a CfC?

Any of those are acceptable; it just needs to be a clear public statement that we think the incubation is done and ready to move onto the standards track. Mozilla has expressed frustration that we don't do this reliably, which causes some of our finished incubations to get "lost" outside of the standards process even though they have widespread support. @Chris Wilson might add some details once he's back from vacation. This isn't something I think feature owners will have the expertise to do on their own, so https://www.chromium.org/blink/launching-features/#new-feature-prepare-to-ship says to ask your spec mentor for help, and I'll be sending a follow-up change to https://chromium-review.googlesource.com/c/website/+/4233971 to tell spec mentors to ask Chris or me for help.

+1 that reducing the risk of incubations getting "lost" is a good thing for us to be doing. I think just filing an issue for some group (with help of mentors) is a very reasonable bar.

I wonder if there's something we can do on the WICG side to make things better here..

[Johann Hofmann]

Hi Jeffrey, thank you for doing all this work!

I want to emphasize that I agree with your goals here and think these are important to work on.

 

https://chromium-review.googlesource.com/c/website/+/4209834: Ask feature authors to propose, before shipping, that a WG take up new features. This doesn't require that a WG _adopt_ before we ship. I'd expected this one to be the most contentious.

That indeed seems very tricky. Do we expect feature owners to open issues proposing a WG migration? Talk to the chairs?

Ask for a CfC?

Any of those are acceptable; it just needs to be a clear public statement that we think the incubation is done and ready to move onto the standards track. Mozilla has expressed frustration that we don't do this reliably, which causes some of our finished incubations to get "lost" outside of the standards process even though they have widespread support. @Chris Wilson might add some details once he's back from vacation. This isn't something I think feature owners will have the expertise to do on their own, so https://www.chromium.org/blink/launching-features/#new-feature-prepare-to-ship says to ask your spec mentor for help, and I'll be sending a follow-up change to https://chromium-review.googlesource.com/c/website/+/4233971 to tell spec mentors to ask Chris or me for help.

+1 that reducing the risk of incubations getting "lost" is a good thing for us to be doing. I think just filing an issue for some group (with help of mentors) is a very reasonable bar.

I wonder if there's something we can do on the WICG side to make things better here.

I'm very concerned about making this change, in that it puts additional work and requirements onto all feature teams at critical moments without any visible evidence that this would have led to success in solving the problem you described in the past. Additionally, it does not come with any resources to support teams with the task. "Ask your spec mentor for help with this" should be used only as a last resort, in my opinion, as it scales badly and adds risk for both teams and spec mentors.

There is a happy path here where feature authors had planned to do this anyway and the reminder helps them to keep track. If we are confident that this represents a large majority of features then I think this is a good change. I'm not sure about it, though.

For features where this assumption doesn't hold, there are likely much more difficult to solve reasons behind why they don't proceed to standardization. If teams try to follow this requirement in good faith you are putting this challenge on them at the most stressful moment in the entire process (before shipping). If they do not, they'll simply file a meaningless issue on a WG that will not get followed up on, which seems like the worst possible outcome.

Either way, outside of the happy path this doesn't seem like a problem we'd want to just put on teams that are sometimes very inexperienced in the web standards world, or their voluntary spec mentors. As such, without specific evidence to the contrary I think that this change is harming launch process participants and the credibility of the process overall.

Instead of this CL, I would like to see a deeper discussion of this problem, with historical examples of where Mozilla expressed concerns about this happening and an exploration of what would have helped move the process along in these cases, i.e. how teams can be *supported* in avoiding undesirable outcomes, at various stages in the process, not just before shipping.

Thanks again,

Johann

[Chris Harrelson]

On Thu, Feb 23, 2023 at 9:47 PM 'Yoav Weiss' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

On Fri, Feb 24, 2023 at 3:07 AM Rick Byers <rby...@chromium.org> wrote:

On Thu, Feb 23, 2023 at 3:03 PM 'Jeffrey Yasskin' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

On Wed, Feb 22, 2023 at 9:55 PM Yoav Weiss <yoav...@google.com> wrote:

On Wed, Feb 22, 2023 at 11:58 PM 'Jeffrey Yasskin' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

https://chromium-review.googlesource.com/c/website/+/4162682: Require the explainer move into a CG by the "widen review" step, which is before OT. This is the change that I referred to in the above I2E thread. I don't think this change implies that a spec needs to be written before the OT starts, but if it does, we should fix that.

As I mentioned in the other thread, I don't believe we have had broader group discussion around that particular point. We previously agreed that specs need to be in an incubation venue for OT extensions beyond 6 milestones, but not necessarily to enter the OT stage.

I think it might make sense, in cases where there's an actual spec at OT time. But that may not always be the case.

So, to start that group discussion: Apple has complained in the past when we ask them for comments on an explainer that's in a personal repo. I think that's reasonable, since the IP grants aren't as clear in a personal repo as they would be in an incubation venue like a CG.

Now, maybe we're not asking Apple for feedback until we have a spec, so we wouldn't have concrete problems with getting feedback on the OT. It's true that the web developers who interact with OTs tend to be less worried about IP issues. But 1) maybe Chromium should be more worried about getting contributions on personal repos that aren't covered by a CLA, and 2) we shouldn't impose IP risks on web developers even if those developers aren't aware of the risks.

If it were expensive to move to a CG, I wouldn't push it at this stage, but the WICG only requires one of the potential OT adopters to say that they're interested in the feature. That seems like a low enough cost that we can ask feature owners to pay it before their OT. There's also no reason you need a spec in order to move to a CG; the WICG adopts explainers all the time.

This seems like reasonable justification and a reasonable bar to me. As long as we have a good venue (like WICG in it's current form) where a single implementer and single customer can collaborate on a design with low overhead, then I'm supportive of this.

Same here, at least for most OTs! Thanks for outlining the reasoning here, Jeffrey! :)

There's a small number of OTs which don't require vendor positions (e.g. we just want to try something out to measure its performance, etc. but with collaborating partners). I think it's fine for those (rare) cases to ask for an exception.

Some of the API owners discussed this at our meeting today (Yoav, Alex, Daniel myself, Mike Taylor). We agreed it would be good to have the feature in a CG or WG by the time of an OT, but don't want to strictly require it, especially in cases where the feature team is not at all sure the feature is a good one to pursue, and wants to run a low-cost experiment to find out more data points to help decide next steps.

Our suggestion: change the language to "recommend" instead of "require", or "strongly recommend" in the case of a new feature, and detail some reasons why it's a good idea to get into a CG or WG before an OT.

Others: WDYT?

 

https://chromium-review.googlesource.com/c/website/+/4209834: Ask feature authors to propose, before shipping, that a WG take up new features. This doesn't require that a WG _adopt_ before we ship. I'd expected this one to be the most contentious.

That indeed seems very tricky. Do we expect feature owners to open issues proposing a WG migration? Talk to the chairs?

Ask for a CfC?

Any of those are acceptable; it just needs to be a clear public statement that we think the incubation is done and ready to move onto the standards track. Mozilla has expressed frustration that we don't do this reliably, which causes some of our finished incubations to get "lost" outside of the standards process even though they have widespread support. @Chris Wilson might add some details once he's back from vacation. This isn't something I think feature owners will have the expertise to do on their own, so https://www.chromium.org/blink/launching-features/#new-feature-prepare-to-ship says to ask your spec mentor for help, and I'll be sending a follow-up change to https://chromium-review.googlesource.com/c/website/+/4233971 to tell spec mentors to ask Chris or me for help.

+1 that reducing the risk of incubations getting "lost" is a good thing for us to be doing. I think just filing an issue for some group (with help of mentors) is a very reasonable bar.

I wonder if there's something we can do on the WICG side to make things better here..

 

Perhaps we should articulate the principle somewhere that we want to go out of our way to foster collaboration but also steadfastly refuse to allow ourselves to be blocked by lack of interest or priority?

Jeffrey

--
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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CANh-dX%3D3jaCa7M1zv9vLTdFVyG6iUXFX7%2BPym7BaAaFNO%2B7ZrA%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.

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

[Jeffrey Yasskin]

On Fri, Feb 24, 2023 at 2:50 AM Johann Hofmann <joha...@google.com> wrote:

Hi Jeffrey, thank you for doing all this work!

I want to emphasize that I agree with your goals here and think these are important to work on.

And thank you for speaking up for the feature teams' interests!

I think we have two kinds of cases that this change would affect, and I'll skip talking about features where the authors would have proposed them for the standards track without this change.

1) Features that other browsers approve of, but would get forgotten in incubation. I think it's clear that looking for a working group is beneficial for these? For these, do we just need to ensure that feature teams can easily find the right way to propose the feature for adoption?

2) Features that other browsers disapprove of, so any proposal to adopt the feature will languish. A team following this requirement in good faith only has to record Chrome's belief that the feature's ready for standardization. They don't need to (and can't) ensure that a working group actually adopts the feature. Is there something in the text that made you think more was required to follow this rule in good faith?

Thanks,

Jeffrey

[Jeffrey Yasskin]

On Wed, Mar 1, 2023 at 9:32 AM Chris Harrelson <chri...@chromium.org> wrote:

On Thu, Feb 23, 2023 at 9:47 PM 'Yoav Weiss' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

On Fri, Feb 24, 2023 at 3:07 AM Rick Byers <rby...@chromium.org> wrote:

On Thu, Feb 23, 2023 at 3:03 PM 'Jeffrey Yasskin' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

On Wed, Feb 22, 2023 at 9:55 PM Yoav Weiss <yoav...@google.com> wrote:

On Wed, Feb 22, 2023 at 11:58 PM 'Jeffrey Yasskin' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

https://chromium-review.googlesource.com/c/website/+/4162682: Require the explainer move into a CG by the "widen review" step, which is before OT. This is the change that I referred to in the above I2E thread. I don't think this change implies that a spec needs to be written before the OT starts, but if it does, we should fix that.

As I mentioned in the other thread, I don't believe we have had broader group discussion around that particular point. We previously agreed that specs need to be in an incubation venue for OT extensions beyond 6 milestones, but not necessarily to enter the OT stage.

I think it might make sense, in cases where there's an actual spec at OT time. But that may not always be the case.

So, to start that group discussion: Apple has complained in the past when we ask them for comments on an explainer that's in a personal repo. I think that's reasonable, since the IP grants aren't as clear in a personal repo as they would be in an incubation venue like a CG.

Now, maybe we're not asking Apple for feedback until we have a spec, so we wouldn't have concrete problems with getting feedback on the OT. It's true that the web developers who interact with OTs tend to be less worried about IP issues. But 1) maybe Chromium should be more worried about getting contributions on personal repos that aren't covered by a CLA, and 2) we shouldn't impose IP risks on web developers even if those developers aren't aware of the risks.

If it were expensive to move to a CG, I wouldn't push it at this stage, but the WICG only requires one of the potential OT adopters to say that they're interested in the feature. That seems like a low enough cost that we can ask feature owners to pay it before their OT. There's also no reason you need a spec in order to move to a CG; the WICG adopts explainers all the time.

This seems like reasonable justification and a reasonable bar to me. As long as we have a good venue (like WICG in it's current form) where a single implementer and single customer can collaborate on a design with low overhead, then I'm supportive of this.

Same here, at least for most OTs! Thanks for outlining the reasoning here, Jeffrey! :)

There's a small number of OTs which don't require vendor positions (e.g. we just want to try something out to measure its performance, etc. but with collaborating partners). I think it's fine for those (rare) cases to ask for an exception.

Some of the API owners discussed this at our meeting today (Yoav, Alex, Daniel myself, Mike Taylor). We agreed it would be good to have the feature in a CG or WG by the time of an OT, but don't want to strictly require it, especially in cases where the feature team is not at all sure the feature is a good one to pursue, and wants to run a low-cost experiment to find out more data points to help decide next steps.

Our suggestion: change the language to "recommend" instead of "require", or "strongly recommend" in the case of a new feature, and detail some reasons why it's a good idea to get into a CG or WG before an OT.

Others: WDYT?

I started https://chromium-review.googlesource.com/c/website/+/4301674 to implement this. The current language already mentioned that we move to CGs to nail down IP commitments; do you want me to add something else, like that CGs also document some of how people should expect to interact?

I wasn't sure what to say about non-new features (small new features that are additions to existing features?) or the use of OTs to test speculative changes. For additions to existing features, presumably the existing feature is already in a CG or WG, and the addition can happen there?

The speculative use of OTs seems to be entirely outside of the documented process, so it's not clear this text would apply at all.

Jeffrey

[Chris Wilson]

My apologies, btw, for not participating in this thread earlier; vacation last week, cold this week.

We need to do something to ensure that when Chromium ships something that is still in incubation, there is at least a good faith effort to move that into a real standardization venue.  We are not doing that today.  If teams are very inexperienced in the web standards world, then they need to get mentoring and support from those who are experienced, or frankly, they should not be designing and shipping features (without that oversight), if our goal long-term is to improve the web standards platform.

On Fri, Feb 24, 2023 at 2:50 AM Johann Hofmann <joha...@google.com> wrote:

[Chris Harrelson]

I think so. I left a comment on the CL.

Thanks for the quick CL!

 

I wasn't sure what to say about non-new features (small new features that are additions to existing features?) or the use of OTs to test speculative changes. For additions to existing features, presumably the existing feature is already in a CG or WG, and the addition can happen there?

Agree that it must already be there if it was shipped somehow.

 

The speculative use of OTs seems to be entirely outside of the documented process, so it's not clear this text would apply at all.

Really? This is one example we had in mind during the discussion. This seems subject to the process, no? e.g. an I2P is needed before landing code.

[Jeffrey Yasskin]

I think experiments like that are currently treated as exceptions where we generally follow the spirit of the process, but I don't think they've happened enough for us to have written down exactly what to do. For example, I couldn't find an I2P corresponding to that feature. I'd interpret that I2E as having been sent before step 3, or maybe even before step 2, where getting to those steps would involve actually designing the hinting mechanism that Ben mentioned. I don't suggest we change anything about the way this sort of I2E is handled. Keep approving them as exceptions, including exceptions to any CG requirement, until there are enough that it's worth writing something down about them.

Jeffrey

[Chris Wilson]

I'm concerned about the mixed guidance we're giving, and I think the speculative/data-collection use of OTs probably should be explicitly identified.  Many OTs are "one step before shipping" - and I would expect that kind to already be in an incubation venue (and that is captured in ITP stage).

[Jeffrey Yasskin]

Sorry for not driving this to a conclusion. Chris Wilson, do you think the change in https://chromium-review.googlesource.com/c/website/+/4301674 results in mixed guidance, or is it still strong enough that you're happy with it?

The speculative use for OTs should be described in the process, but I'd appreciate if someone else wrote that change.

Thanks,

Jeffrey

[Chris Wilson]

Sorry this has taken me several days to focus on.  I think I'm concerned that it softens the guidance quite a bit, without describing WHY this might occur - or more to the point, in what circumstances this might happen, or when it's okay to not be in an incubation venue.  This is specifically only a carve-out for features we're taking to I2E with the intent to return to dev trial (e.g. data collection OT), isn't it?

[Yoav Weiss]

Made a suggestion on https://chromium-review.googlesource.com/c/website/+/4301674/3/site/blink/launching-features/index.md#234

PTAL to see if this works for y'all.