Important: change to the "browser signals" section of the intent-to-ship process
174 views
Skip to first unread message
Chris Harrelson
May 26, 2020, 2:22:22 PM5/26/20
to blink-dev
Hi,
TL;DR: new intents-to-ship will need a more formalized "other implementation signals" section in place of today's "browser signals". This will require some explicit actions for Gecko and WebKit, as well as allowing time for their response.
--
The API owners plan to start enforcing this soon (after a grace period for in-progress features that are already about to ship, and some time for any additional feedback on this planned change).
This document outlines the new process. Its purpose is to make the "browser signals" part of the intent-to-ship template (the one that asks what Firefox and Safari think) more precise and avoid certain problems that arose in past intents. The motivation for the change is discussed in this thread (which you're welcome to add your views to).
Thanks,
Chris, on behalf of the API owners
fantasai
May 26, 2020, 5:32:19 PM5/26/20
to blink-api-ow...@chromium.org, blin...@chromium.org
Hi!
I think these changes move in a positive direction with respect to clearly
taking into consideration other browser vendors' views on features that Chrome
wants to ship, and I regard them as an improvement.
However, they do create a duplicate of processes already in place in the
standards groups. While this may be needed needed in cases where Chrome is
moving faster than the relevant specs, it's not needed in cases where the spec
is ahead and Chrome devs merely want to implement such consensus-backed specs.
For example, a CR spec issued by CSSWG implicitly has the backing of the
entire CSSWG, including all major browser vendors: if it didn't, the
resolution to transition to CR would not go through. This signal is worth
recording, and soliciting individual signals from each vendor becomes
considerably less necessary. Similarly, CSSWG has in place a process to take
resolutions on features that are not yet in a CR draft, officially clearing
them for shipping in implementations. The discussion triggered by such
requests helps to bring to light any significant unsolved issues and concerns
that members know about, that could significantly impact an implementation or
create undesirable Web-compat issues should an implementation ship the
currently-specced features. I'm sure TC39 and other groups have similar
procedures.
Not taking even explicit WG positions, such as issuing an official call for
implementations, into consideration duplicates existing discussions in the
case of features which have already passed these thresholds. Skipping out of
triggering those official discussions in favor of bilateral queries also
shifts discussion around generating consensus around features from
vendor-neutral standards fora with broader participation to vendor-specific
fora with narrower participation, which undermines the vendor-neutral
standards processes.
To the extent that Chrome occasionally wishes to override outcomes of such
processes for some reason, or in topic areas where a functioning standards
group does not exist, it makes sense. But in the general case, I believe
Chrome wants to participate in standards as the best Web citizen it can be,
and not taking recognized standards processes into consideration in its ITS
procedures does not serve that goal.
~fantasai
Chris Harrelson wrote on 2020-03-26 to blink-api-owners-discuss in
“Formalizing signals from other browsers in intent-to-ship”:
>
> I think we need to strictly formalize what is allowed to be put in the
"signals" section of an intent-to-ship. The reason is that:
> * Representatives of other browsers do not want to be (even accidentally)
misrepresented
> * It causes them to be cautious when responding to requests for feedback on
features, thinking it might become a signal
>
> I suggest we have five possible values: No Signals, Positive, Neutral,
Negative, and Shipped/Shipping.
>
> For each other major browser, we list an explicit method to get signals
different than No Signals. e.g. from Mozilla, we say that you need to file a
standards-positions issue and wait for response. For WebKit you need to email
webkit-dev and wait for a response from one of the WebKit leads. If a feature
is shipped or about to ship, just find out in what version it is shipped/will
be shipping and says so with a quick link to evidence.
>
> These steps are not strictly required. It's ok to say No Signals in your
intent, though API owners will ask for evidence of outreach etc. as usual.
It'll just not be ok to say Positive without the above steps.
>
> Any other relevant data regarding comments from other browser vendors in
public settings can be added as context or evidence for
outreach/consensus-building as part of shipping (e.g. a CSSWG resolution is
useful data), so long as it is not construed to influence the "signals"
statement of a particular browser.
>
> Thoughts?
Chris Harrelson wrote on 2020-05-26 to blink-dev in “Important: change to the
"browser signals" section of the intent-to-ship process”:
> Hi,
>
> TL;DR: new intents-to-ship will need a more formalized "other
implementation signals" section in place of today's "browser signals". This
will require some explicit actions for Gecko and WebKit, as well as allowing
time for their response.
>
I think these changes move in a positive direction with respect to clearly
taking into consideration other browser vendors' views on features that Chrome
wants to ship, and I regard them as an improvement.
However, they do create a duplicate of processes already in place in the
standards groups. While this may be needed needed in cases where Chrome is
moving faster than the relevant specs, it's not needed in cases where the spec
is ahead and Chrome devs merely want to implement such consensus-backed specs.
For example, a CR spec issued by CSSWG implicitly has the backing of the
entire CSSWG, including all major browser vendors: if it didn't, the
resolution to transition to CR would not go through. This signal is worth
recording, and soliciting individual signals from each vendor becomes
considerably less necessary. Similarly, CSSWG has in place a process to take
resolutions on features that are not yet in a CR draft, officially clearing
them for shipping in implementations. The discussion triggered by such
requests helps to bring to light any significant unsolved issues and concerns
that members know about, that could significantly impact an implementation or
create undesirable Web-compat issues should an implementation ship the
currently-specced features. I'm sure TC39 and other groups have similar
procedures.
Not taking even explicit WG positions, such as issuing an official call for
implementations, into consideration duplicates existing discussions in the
case of features which have already passed these thresholds. Skipping out of
triggering those official discussions in favor of bilateral queries also
shifts discussion around generating consensus around features from
vendor-neutral standards fora with broader participation to vendor-specific
fora with narrower participation, which undermines the vendor-neutral
standards processes.
To the extent that Chrome occasionally wishes to override outcomes of such
processes for some reason, or in topic areas where a functioning standards
group does not exist, it makes sense. But in the general case, I believe
Chrome wants to participate in standards as the best Web citizen it can be,
and not taking recognized standards processes into consideration in its ITS
procedures does not serve that goal.
~fantasai
Chris Harrelson wrote on 2020-03-26 to blink-api-owners-discuss in
“Formalizing signals from other browsers in intent-to-ship”:
>
> I think we need to strictly formalize what is allowed to be put in the
"signals" section of an intent-to-ship. The reason is that:
> * Representatives of other browsers do not want to be (even accidentally)
misrepresented
> * It causes them to be cautious when responding to requests for feedback on
features, thinking it might become a signal
>
> I suggest we have five possible values: No Signals, Positive, Neutral,
Negative, and Shipped/Shipping.
>
> For each other major browser, we list an explicit method to get signals
different than No Signals. e.g. from Mozilla, we say that you need to file a
standards-positions issue and wait for response. For WebKit you need to email
webkit-dev and wait for a response from one of the WebKit leads. If a feature
is shipped or about to ship, just find out in what version it is shipped/will
be shipping and says so with a quick link to evidence.
>
> These steps are not strictly required. It's ok to say No Signals in your
intent, though API owners will ask for evidence of outreach etc. as usual.
It'll just not be ok to say Positive without the above steps.
>
> Any other relevant data regarding comments from other browser vendors in
public settings can be added as context or evidence for
outreach/consensus-building as part of shipping (e.g. a CSSWG resolution is
useful data), so long as it is not construed to influence the "signals"
statement of a particular browser.
>
> Thoughts?
Chris Harrelson wrote on 2020-05-26 to blink-dev in “Important: change to the
"browser signals" section of the intent-to-ship process”:
> Hi,
>
> TL;DR: new intents-to-ship will need a more formalized "other
implementation signals" section in place of today's "browser signals". This
will require some explicit actions for Gecko and WebKit, as well as allowing
time for their response.
>
Chris Harrelson
May 27, 2020, 1:56:49 PM5/27/20
to fantasai, blink-api-owners-discuss, blink-dev
Hi Elika,
The status of a spec in terms of acceptance level in a standards body is in fact taken into account during intent-to-ship, and the more there is the better a signal that is for the API owners to evaluate risk. For example, we often look at the stage of TC39 that a JavaScript language-related intent has reached as a signal of general approval from the web standards community. In the case of CSS intents, you're right that it's not often the case that an intent author will point out whether a spec for the feature has advanced to CR, nor do the API owners currently go out of our way to look for that actively right now. On the other hand, we do treat CSSWG resolutions as important signals of consensus.
I'm also glad you agree that Chrome wants to participate as a good citizen in the web; we certainly do! :)
As for duplication of effort: I respectfully disagree. Just because a spec has reached broad consensus in a standards body does not mean that any browser is planning to implement it in the near future, even if that standards body includes representatives of all browsers. In the particular case of CSS, I see this quite often, since there are a truly huge number of specs and features there, many of which are only partially implemented. It's not reasonable given anything near current staffing for browsers to implement all the specs, regardless of their interest. For that reason, it makes a lot of sense to me to ask the other browsers their views and whether they intend to implement soon; maybe they would! In which case the web is better off. In fact, the reason they didn't implement may be that they are just waiting around for other browsers to take action, or forgot about the feature, or didn't know about additional potential reasons to prioritize it.
A third point related to your comments about web compat and spec quality: it is also common that browser engineers will take a much closer look at a spec when trying to implement and ship it than they might have earlier on. In my experience, problems like web compat, errors or unclarity in the specs, or an aspect that is too difficult to implement often come up during this stage. This is inevitable because it's really difficult to reason fully about a complex spec in a complex product like a web browser without going through the work of trying to implement it. A great recent example is flexbox gutters; in this case, the Chromium engineers realized a flaw in the spec during implementation, even though that spec is relatively mature. Chromium is not at all unique in this regard; similar flaws in specs often come up when other browsers' engineers look closer at a spec or try to implement it. The sooner we can get attention on finding potential flaws the better, and there is no more important time to do so than when a browser is considering shipping an implementation of the spec, which if shipped with a flaw will be hard to change.
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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/13684a63-0672-4df4-dd93-1ca20ec07a1e%40inkedblade.net.
Nicolás Peña
May 28, 2020, 9:52:28 AM5/28/20
to blink-dev, fantasa...@inkedblade.net, blink-api-ow...@chromium.org
Could the Intents template doc be updated to reflect these changes? Thanks!
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
Johnny Stenback
May 28, 2020, 11:56:36 AM5/28/20
to Nicolás Peña, blink-dev, fantasa...@inkedblade.net, blink-api-owners-discuss
Given that the launch process is moving to the chromestatus tool, we will not be updating the templates document any more. I just made that clear in the document itself. Going forward, please file issues on the chromestatus tool repo for changes to the templates that it generates.
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/13684a63-0672-4df4-dd93-1ca20ec07a1e%40inkedblade.net.
--
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/38b54fab-0a6c-4334-a175-2b79a350fe37%40chromium.org.
Nicolás Peña
May 28, 2020, 12:16:29 PM5/28/20
to blink-dev, n...@chromium.org, fantasa...@inkedblade.net, blink-api-ow...@chromium.org
FWIW I disagree with the decision to deprecate the doc templates right now. I use them to generate a doc so I can get a second pair of eyes to look at my Intent before sending it. This is not really possible with chromestatus right now, as far as I know. All I can think of doing is creating the feature, and then copying the generated email content into a google doc so it can be looked at before sending it. Then I'd have to remember to apply any changes resulting from the doc onto the chromestatus entry as well, before I actually send the Intent. Of course the doc is not ideal, as it still requires updating chromestatus, which I sometimes forget to do when the entry has already been created, but it seems better. What's the suggested workflow for reviewing intents before they're sent to blink-dev, when they are started from chromestatus?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/13684a63-0672-4df4-dd93-1ca20ec07a1e%40inkedblade.net.
--
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+unsubscribe@chromium.org.
Marijn Kruisselbrink
May 28, 2020, 12:30:32 PM5/28/20
to Nicolás Peña, blink-dev, fantasa...@inkedblade.net, blink-api-owners-discuss
I completely agree with this. Until the new chromestatus tool is actually ready and fully functional it seems way premature to deprecate the docs.
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/13684a63-0672-4df4-dd93-1ca20ec07a1e%40inkedblade.net.
--
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/38b54fab-0a6c-4334-a175-2b79a350fe37%40chromium.org.
--
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/a2028272-bc5a-428f-8185-f97e14130a6c%40chromium.org.
David Benjamin
May 28, 2020, 3:08:26 PM5/28/20
to Marijn Kruisselbrink, Nicolás Peña, blink-dev, fantasa...@inkedblade.net, blink-api-owners-discuss
I've also avoided the chromestatus tool for this reason. My workflow is to copy the template into a doc, fill it out, then ask my team members to review it to help catch mistakes. Then I'll fill out the chromestatus bits and send the email in one go. The tool as-is appears to generate the Intent mail after publishing the status entry, but that means all my typos get published.
I guess then the workflow would be to copy and paste the chromestatus form itself into a doc, and then paste it back in after folks look it over?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BOSsVZ5W4SD1%3DG6encQ29HRNrVC%2BcbqEOsbxdqr%2BpYsLEfDhA%40mail.gmail.com.
Ben Kelly
May 28, 2020, 3:12:02 PM5/28/20
to David Benjamin, Marijn Kruisselbrink, Nicolás Peña, blink-dev, fantasa...@inkedblade.net, blink-api-owners-discuss
Also, as noted previously, there are long standing bugs in chromestatus that prevent using it this way:
(Also +1 to seeing the output before I submit it publicly...)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAF8qwaAtOacJ0x3VPZ4C2nCw2z7hdUsqh7tQLjS0-d1z-PujNw%40mail.gmail.com.
Johnny Stenback
May 28, 2020, 6:31:44 PM5/28/20
to Ben Kelly, David Benjamin, Marijn Kruisselbrink, Nicolás Peña, blink-dev, fantasa...@inkedblade.net, blink-api-owners-discuss
Fair enough, sorry for jumping the gun on this. I reverted the changes I made to the document templates for now, and added a banner talking clearly about the intent. And I've also spun up an effort to fix the small number of issues that have been pointed out as blocking this on the chromestatus.com side (including the ability to draft features w/o making them public), and those will be prioritized now.
Thanks,
Johnny
- jstenback (he/him)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAK7rkMieZdf%3Dn5V3TPHEt-p4LYT%3DzSc2%2BcvU-sxG6ySXegUojQ%40mail.gmail.com.
Chris Harrelson
May 28, 2020, 8:28:08 PM5/28/20
to Johnny Stenback, Marijn Kruisselbrink, blink-dev, blink-api-owners-discuss
I went ahead and edited the template to remove the browser signals fields and replace them with:
Signals from other implementations (Gecko, WebKit): fill in according to instructions in this document.
Another point: the API owners met today and decided that we'll start enforcing this new step as of July 1, 2020 (first day of Q3). We recommend that intent-to-ships sent before that date use the new step, but won't require it until then.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACZRgz5eK1hKT0G%3DxYs9S75CGpcdLDpD2VWLz6KMEGhNMmVG6A%40mail.gmail.com.
Chris Harrelson
Jul 9, 2020, 1:45:53 PM7/9/20
to blink-dev
Quick update: the API owners will be enforcing these changes for new intents starting next week. If you are working on an intent, please read the update - it likely means you need to take one or more steps to obtain the signals, as well as wait a suitable period for replies.
Thanks,
Chris, on behalf of the API owners.
Reply all
Reply to author
Forward
0 new messages