Formalizing signals from other browsers in intent-to-ship

[Chris Harrelson]

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

[Thomas Steiner]

+1. I have no “API owners” say or anything, but as DevRel I’m always like 🤔 when I see a statement à la “Web Developers: Positive” but without a link. Can we make linking obligatory?

--
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/CA%2BN6QZspmn3nWjp2%2BOVeRfoaxPO1E7oP6oX2Mgkzn%2BBi9Jz3HQ%40mail.gmail.com.

--

Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com, https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1.23 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/
-----END PGP SIGNATURE-----

[Johnny Stenback]

We certainly can make the link obligatory if we deem that the right thing to do (which I would agree with).

Cheers,

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/CALgRrLn%3DEMnjO03t67nQk2E%3Da8eCLiKdXzpYygvSOHin%2BzDJgg%40mail.gmail.com.

[Ben Kelly]

If you are discussing the API with partners in private channels and they show interest, does this mean they would need to go on the record in some public forum so it could be linked?  I understand some partners have been resistant to this in the past.

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

[Adam Klein]

While I agree that the current "signals" has problems as Chris outlined, I worry about the additional legwork this requires for folks working on features (as well as adding dependencies on other channels that may not be equipped to handle the additional load). So for me this comes down to the details of the explicit methods for each vendor.

--

[Chris Harrelson]

All: these are good points.

If the requirement was as simple as filing a bug in two places, and doing so with enough lead time to provide a "reasonable" amount of time for reply, do you think that would be acceptable?

What if there was a carveout for "trival" or "obvious" intents that could skip this step? e.g. a minor addition to date formatting in JavaScript that had been ratified up to stage 3? A case like that seems overkill to have to file "What's Safari's opinion?"-type bugs.

[PhistucK]

I think a reasonable answer for signals of JavaScript intents is a single link to the proposal status at the TC39 repository. Stage 3 means agreement from the browsers, so that unequivocally counts as positive signals from all vendors (no need to even list specific vendors).

For non-JavaScript intents, it is case by case, but it would be good to indicate signals for any feature, regardless of how small or trivial it is. "Just another property" is not a good justification for not getting signals, generally.

☆PhistucK

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

[Domenic Denicola]

On Sat, Mar 28, 2020 at 11:59 AM PhistucK <phis...@gmail.com> wrote:

I think a reasonable answer for signals of JavaScript intents is a single link to the proposal status at the TC39 repository. Stage 3 means agreement from the browsers, so that unequivocally counts as positive signals from all vendors (no need to even list specific vendors).

This isn't really accurate. It doesn't mean positive, and it doesn't even mean non-negative; it just means that the browser (and other committee members) were not willing to veto the proposal in question.

Empirically, stage 3 proposals sometimes land quickly in other engines with support of the browsers behind them, or sometimes land very slowly, often only via third-party contributions. (E.g. BigInt was promoted to stage 3 in July 2017 but is still in only 2 engines.) So when judging to what extent they will become an interoperable part of the platform, stage 3 is not particularly helpful.

While I think the risk tradeoff is somewhat different for stage 3 proposals vs. other features, I would be very hesitant to automatically ascribe them any sort of signals.

 

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

[sheldonja...@hotmail.com]

[sheldonja...@hotmail.com]

On Thursday, 26 March 2020 12:02:14 UTC-6, Chris Harrelson wrote:

[sheldonja...@hotmail.com]

On Thursday, 26 March 2020 12:02:14 UTC-6, Chris Harrelson wrote:

[sheldonja...@hotmail.com]

On Thursday, 26 March 2020 12:02:14 UTC-6, Chris Harrelson wrote:

[Chris Harrelson]

I have written up a draft modification of the intent-to-ship process that formalizes what I am calling the Implementation Signals List.

Important points to note:

* I renamed from "Browser" to "Implementer", to make clear it's about finding out about signals from the non-Chromium implementations of the web, as opposed to specific browser brands.

* The list (including specific per-browser actions in advance of sending intent-to-ship) is marked as required. N/A is a possible value, but must be justified on a case-by-case basis.

* I didn't write down any process for Edge or Chrome. This is because they share the same implementation, and there is ample opportunity for them to contribute opinions directly to the intent-to-ship on blink-dev, as well as via many other forums during the Chromium implementation process, just as other Chromium embedders such as Opera and Samsung Internet do.

[Chris Harrelson]

Also, not sure what is going on with Chromium sharing today; the option to make it public to non-chromium contributors is not working. I shared it with chromium and everyone who is on this thread.

On Sat, Mar 28, 2020 at 10:37 AM Domenic Denicola <dom...@chromium.org> wrote:

[Daniel Bratell]

I think this looks fine. If we can get something close to this in the process and in the guide then it should clearly remove, or reduce, a source for misunderstandings and also prevent delays caused by such misunderstandings.

/Daniel

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

[Chris Wilson]

Hmm.  I am a little concerned that the tracking for other implementations will be clearly tracked in Chromestatus, but the signals from Chrome/Edge will just end up being "look at the blink-dev thread".  I think we should think through how this should work in a trackable-in-Chromestatus way for features driven by Chrome as well as features driven by Edge, or Igalia or any other Chromium contributor.  Edge will want to point to Google signals for features they're committing, at the very least (or so I have heard from them).  I'm not sure I agree that only "the other two engines that might have implementations" are the only pivot we should be capturing.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/340d89ab-f675-6886-c821-6792646322dc%40gmail.com.

[Chris Harrelson]

To me, the main value of the current Safari / Firefox signals section is estimating the likelihood of eventual adoption by all three of the key implementations of the web APIs, and therefore interop. Since Edge, Chrome, Samsung Internet, Opera, Brave, UC, and several others share an implementation, there is much less risk (in practice so far, almost zero; examples I can think of so far are some specific features in the case of Brave) of them failing to ship a feature supported by their codebase. Furthermore, there is already a voice available for them as members of the Blink community to raise objections at multiple points in the Intent process. Also, collecting signals from each and every embedder of Blink is quite onerous.

Chris

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

[Chris Harrelson]

Any more thoughts?

[Chris Harrelson]

Ping? Can we just make this change?

[Mike West]

I am in favor of this change. LGTM1. :)

-mike

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

[Yoav Weiss]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAKXHy%3DcPdZWDVOGDYt_v-e_sV-4djW_qfKTHowgYUyya6Kr%3D1g%40mail.gmail.com.

[Manuel Rego Casasnovas]

LGTM3

> <mailto:blink-api-ow...@chromium.org>> wrote:
>
> Hmm.  I am a little concerned that the tracking for
> other implementations will be clearly tracked in
> Chromestatus, but the signals from Chrome/Edge will
> just end up being "look at the blink-dev thread".  I
> think we should think through how this should work
> in a trackable-in-Chromestatus way for features
> driven by Chrome as well as features driven by Edge,
> or Igalia or any other Chromium contributor.  Edge
> will want to point to Google signals for features
> they're committing, at the very least (or so I have
> heard from them).  I'm not sure I agree that only
> "the other two engines that might have
> implementations" are the only pivot we should be
> capturing.
>
> On Fri, May 8, 2020 at 10:36 AM Daniel Bratell

> <brat...@gmail.com <mailto:brat...@gmail.com>>

> wrote:
>
> I think this looks fine. If we can get something
> close to this in the process and in the guide
> then it should clearly remove, or reduce, a
> source for misunderstandings and also prevent
> delays caused by such misunderstandings.
>
> /Daniel
>
> On 2020-05-01 02:24, Chris Harrelson wrote:
>> Also, not sure what is going on with Chromium
>> sharing today; the option to make it public to
>> non-chromium contributors is not working. I
>> shared it with chromium and everyone who is on
>> this thread.
>>
>> On Sat, Mar 28, 2020 at 10:37 AM Domenic
>> Denicola <dom...@chromium.org

>> <mailto:dom...@chromium.org>> wrote:
>>
>>
>>
>> On Sat, Mar 28, 2020 at 11:59 AM PhistucK
>> <phis...@gmail.com

>> ☆*PhistucK*

>>
>>
>> On Fri, Mar 27, 2020 at 11:56 PM Chris
>> Harrelson <chri...@chromium.org

>> <mailto:chri...@chromium.org>> wrote:
>>
>> All: these are good points.
>>
>> If the requirement was as simple
>> as filing a bug in two places, and
>> doing so with enough lead time to
>> provide a "reasonable" amount of
>> time for reply, do you think that
>> would be acceptable?
>>
>> What if there was a carveout for
>> "trival" or "obvious" intents that
>> could skip this step? e.g. a minor
>> addition to date formatting in
>> JavaScript that had been ratified
>> up to stage 3? A case like that
>> seems overkill to have to file
>> "What's Safari's opinion?"-type bugs.
>>
>>
>>
>> On Fri, Mar 27, 2020 at 12:46 PM
>> Adam Klein <ad...@chromium.org

>> <mailto:ad...@chromium.org>> wrote:
>>
>> While I agree that the current
>> "signals" has problems as
>> Chris outlined, I worry about
>> the additional legwork this
>> requires for folks working on
>> features (as well as adding
>> dependencies on other channels
>> that may not be equipped to
>> handle the additional load).
>> So for me this comes down to
>> the details of the explicit
>> methods for each vendor.
>>
>> On Thu, Mar 26, 2020 at 11:02
>> AM Chris Harrelson
>> <chri...@chromium.org

>> <mailto: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/CA%2BN6QZspmn3nWjp2%2BOVeRfoaxPO1E7oP6oX2Mgkzn%2BBi9Jz3HQ%40mail.gmail.com

>> <https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZspmn3nWjp2%2BOVeRfoaxPO1E7oP6oX2Mgkzn%2BBi9Jz3HQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>>
>> --
>> 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

>> <mailto: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/CA%2BN6QZskFWEnOeVB4QmrtPzH8QyPcpOu-tfSNTiL7sDJZ-wsRA%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZskFWEnOeVB4QmrtPzH8QyPcpOu-tfSNTiL7sDJZ-wsRA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>>
>> --
>> 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

>> <mailto: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/CABc02_Lq_PZh58UG9fapitH1%2B_x60ZD0%3D_H_fZEm75yJjeNLKQ%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CABc02_Lq_PZh58UG9fapitH1%2B_x60ZD0%3D_H_fZEm75yJjeNLKQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>>
>> --
>> 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

>> <mailto: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/CA%2BN6QZvRo7RgrTpUgBfzFRJsJREftWxrfhe-VmtsqHOw_0syBQ%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZvRo7RgrTpUgBfzFRJsJREftWxrfhe-VmtsqHOw_0syBQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> 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 <mailto: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/340d89ab-f675-6886-c821-6792646322dc%40gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/340d89ab-f675-6886-c821-6792646322dc%40gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto: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/CAJK2wqUeWp1MX4My8LpnDNWo8dugwAwWh9Pe%2BKcezUaNyoRnkg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAJK2wqUeWp1MX4My8LpnDNWo8dugwAwWh9Pe%2BKcezUaNyoRnkg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto: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/CA%2BN6QZvnSFQ8wq0wEOmHGAgBFcp86wtFtAJ2EgGxFVC5JV1K-w%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZvnSFQ8wq0wEOmHGAgBFcp86wtFtAJ2EgGxFVC5JV1K-w%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto: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/CAKXHy%3DcPdZWDVOGDYt_v-e_sV-4djW_qfKTHowgYUyya6Kr%3D1g%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAKXHy%3DcPdZWDVOGDYt_v-e_sV-4djW_qfKTHowgYUyya6Kr%3D1g%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto: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/CAL5BFfWbBD32Sdw%3DaB86m%3D%2BBBdQnQ__c-gQX43kNqcgC2SRXgg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAL5BFfWbBD32Sdw%3DaB86m%3D%2BBBdQnQ__c-gQX43kNqcgC2SRXgg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[TAMURA, Kent]

The document LGTM.

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/c0e6d80d-2564-e188-0cba-680ee55ae70f%40igalia.com.

--

TAMURA Kent
Software Engineer, Google

[Chris Harrelson]

Ok thanks. I'm going to go ahead and send this document to blink-dev as a heads-up, with a statement that we'll start requiring this for new intents (with some grace period for existing intents that are almost done).

[fantasai]

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”:

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.
>
> 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).

[Chris Harrelson]

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]

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]

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]

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]

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]

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]

Also, as noted previously, there are long standing bugs in chromestatus that prevent using it this way:

https://github.com/GoogleChrome/chromium-dashboard/issues/707 

(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]

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]

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.