Request for feedback: required developer signals during an intent-to-ship

[Chris Harrelson]

Hi community,

+Thomas Steiner has proposed that we add a more detailed methodology to gathering and reporting developer signals in an intent-to-ship. The largest part of the proposed change is that an intent-to-ship will now require developer signals, and a clear explanation of why not if there are none. The document linked below goes into details about what constitutes a signal and how to get help finding signals for your features.

https://goo.gle/developer-signals

The API owners have reviewed this plan and think it is a good improvement to the process, but we'd like to get more feedback from the entire community before finalizing this change. Please let us know, either on this thread, or on the blink-api-owners-discuss thread, of any concerns or feedback

Thanks,

Chris

[Shu-yu Guo]

Hi Chris and API owners,

What are your thoughts on proposals that have reached consensus in TC39? TC39 has many stakeholders, including both practitioners and browser vendors. Would having reached consensus at TC39 or similar consensus-seeking bodies with wide stakeholder representation (like the Wasm CG) count as having positive developer signal?

Thanks,

shu

--
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/CAOMQ%2Bw94rkFdoLpbunJjPhWjq%2BKjEROjbcokUsjcBET3ziiN-A%40mail.gmail.com.

[Chris Harrelson]

Hi Shu,

On Fri, Jan 22, 2021 at 2:30 PM Shu-yu Guo <s...@chromium.org> wrote:

Hi Chris and API owners,

What are your thoughts on proposals that have reached consensus in TC39? TC39 has many stakeholders, including both practitioners and browser vendors. Would having reached consensus at TC39 or similar consensus-seeking bodies with wide stakeholder representation (like the Wasm CG) count as having positive developer signal?

Good question. I don't think it's quite enough to expect TC39 to already take into account developer signals and rely upon that. For one thing, the blink-dev community not involved with TC39 wouldn't hear those signals, which keeps us from benefiting from their wisdom. For another, while I'm sure TC39 does a good job listening to everyone, other standards groups would make similar claims and then there'd be a slippery slope...

I think it's better for us all to get in the habit of communicating well with the community why we're doing stuff, which will in my personal experience help us learn better the purpose and potential of our own features, and also help others gain wisdom as well. It will also help to explain to other browser vendors why they should support a feature, and the same for developers who haven't encountered the feature yet.

Would it be easy enough to get evidence of these signals from the TC39 meeting minutes, or quick questions to practitioners along the way? I get it that it's a burden to have to go do that for a feature about to ship right now, but for future ones?

Chris

 

On Fri, Jan 22, 2021 at 12:16 PM Chris Harrelson <chri...@chromium.org> wrote:

Hi community,

+Thomas Steiner has proposed that we add a more detailed methodology to gathering and reporting developer signals in an intent-to-ship. The largest part of the proposed change is that an intent-to-ship will now require developer signals, and a clear explanation of why not if there are none. The document linked below goes into details about what constitutes a signal and how to get help finding signals for your features.

https://goo.gle/developer-signals

The API owners have reviewed this plan and think it is a good improvement to the process, but we'd like to get more feedback from the entire community before finalizing this change. Please let us know, either on this thread, or on the blink-api-owners-discuss thread, of any concerns or feedback

Thanks,

Chris

--
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/CAOMQ%2Bw94rkFdoLpbunJjPhWjq%2BKjEROjbcokUsjcBET3ziiN-A%40mail.gmail.com.

--
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/CAN-e9e8U-_%3Dy3NFYkwL9miRduYfjGE5z1yS8imhGduVkRN1yZQ%40mail.gmail.com.

[Shu-yu Guo]

Thanks for the answers, I have some inline response below.

I have another question. Historically there have been features that end up being very controversial with developers but nevertheless reached consensus. These features usually have prodigious amounts of discussion material from the developer community, much of which requires significant context to understand the nuance of, and much of which is noise. It will be a significant burden, if possible at all, to try to distill the public feedback into something digestible for API owner review. What kind of "primary source" material would the API owners be looking for in that case?

On Fri, Jan 22, 2021 at 4:51 PM Chris Harrelson <chri...@chromium.org> wrote:

Hi Shu,

On Fri, Jan 22, 2021 at 2:30 PM Shu-yu Guo <s...@chromium.org> wrote:

Hi Chris and API owners,

What are your thoughts on proposals that have reached consensus in TC39? TC39 has many stakeholders, including both practitioners and browser vendors. Would having reached consensus at TC39 or similar consensus-seeking bodies with wide stakeholder representation (like the Wasm CG) count as having positive developer signal?

Good question. I don't think it's quite enough to expect TC39 to already take into account developer signals and rely upon that. For one thing, the blink-dev community not involved with TC39 wouldn't hear those signals, which keeps us from benefiting from their wisdom. For another, while I'm sure TC39 does a good job listening to everyone, other standards groups would make similar claims and then there'd be a slippery slope...

I think it's better for us all to get in the habit of communicating well with the community why we're doing stuff, which will in my personal experience help us learn better the purpose and potential of our own features, and also help others gain wisdom as well. It will also help to explain to other browser vendors why they should support a feature, and the same for developers who haven't encountered the feature yet.

Would it be easy enough to get evidence of these signals from the TC39 meeting minutes, or quick questions to practitioners along the way? I get it that it's a burden to have to go do that for a feature about to ship right now, but for future ones?

The TC39 plenary minutes are quite detailed (almost verbatim nowaday, we're experimenting with speech transcription), so if the signals are there, they should be easy to find.

Additionally there are non-plenary calls for specific audiences, like the Frameworks call where a certain audience's opinions are elicited. Minutes from that would have signals as well.

I'll refrain from stronger pushback for now and see how cumbersome this turns out to be in practice.

[Chris Harrelson]

On Fri, Jan 22, 2021 at 5:15 PM Shu-yu Guo <s...@chromium.org> wrote:

Thanks for the answers, I have some inline response below.

I have another question. Historically there have been features that end up being very controversial with developers but nevertheless reached consensus. These features usually have prodigious amounts of discussion material from the developer community, much of which requires significant context to understand the nuance of, and much of which is noise. It will be a significant burden, if possible at all, to try to distill the public feedback into something digestible for API owner review. What kind of "primary source" material would the API owners be looking for in that case?

I suppose in these cases you'd say there is mixed positive/negative support. There is no choice in the table in the document I linked to for that, we should add it. I will take an action item to do so.

In these cases I'd suggest linking to representative comments in each direction.

 

On Fri, Jan 22, 2021 at 4:51 PM Chris Harrelson <chri...@chromium.org> wrote:

Hi Shu,

On Fri, Jan 22, 2021 at 2:30 PM Shu-yu Guo <s...@chromium.org> wrote:

Hi Chris and API owners,

What are your thoughts on proposals that have reached consensus in TC39? TC39 has many stakeholders, including both practitioners and browser vendors. Would having reached consensus at TC39 or similar consensus-seeking bodies with wide stakeholder representation (like the Wasm CG) count as having positive developer signal?

Good question. I don't think it's quite enough to expect TC39 to already take into account developer signals and rely upon that. For one thing, the blink-dev community not involved with TC39 wouldn't hear those signals, which keeps us from benefiting from their wisdom. For another, while I'm sure TC39 does a good job listening to everyone, other standards groups would make similar claims and then there'd be a slippery slope...

I think it's better for us all to get in the habit of communicating well with the community why we're doing stuff, which will in my personal experience help us learn better the purpose and potential of our own features, and also help others gain wisdom as well. It will also help to explain to other browser vendors why they should support a feature, and the same for developers who haven't encountered the feature yet.

Would it be easy enough to get evidence of these signals from the TC39 meeting minutes, or quick questions to practitioners along the way? I get it that it's a burden to have to go do that for a feature about to ship right now, but for future ones?

The TC39 plenary minutes are quite detailed (almost verbatim nowaday, we're experimenting with speech transcription), so if the signals are there, they should be easy to find.

Additionally there are non-plenary calls for specific audiences, like the Frameworks call where a certain audience's opinions are elicited. Minutes from that would have signals as well.

I'll refrain from stronger pushback for now and see how cumbersome this turns out to be in practice.

Ok thanks. I hope you don't need convincing that the API owners are reasonable and we'll always listen to feedback. :)

 

 

Chris

 

On Fri, Jan 22, 2021 at 12:16 PM Chris Harrelson <chri...@chromium.org> wrote:

Hi community,

+Thomas Steiner has proposed that we add a more detailed methodology to gathering and reporting developer signals in an intent-to-ship. The largest part of the proposed change is that an intent-to-ship will now require developer signals, and a clear explanation of why not if there are none. The document linked below goes into details about what constitutes a signal and how to get help finding signals for your features.

https://goo.gle/developer-signals

The API owners have reviewed this plan and think it is a good improvement to the process, but we'd like to get more feedback from the entire community before finalizing this change. Please let us know, either on this thread, or on the blink-api-owners-discuss thread, of any concerns or feedback

Thanks,

Chris

--
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/CAOMQ%2Bw94rkFdoLpbunJjPhWjq%2BKjEROjbcokUsjcBET3ziiN-A%40mail.gmail.com.

--
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/CAN-e9e8U-_%3Dy3NFYkwL9miRduYfjGE5z1yS8imhGduVkRN1yZQ%40mail.gmail.com.

--
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/CAN-e9e-wHz0ppG_a%3DwB0oHiK-snrM7DpktFGzd%2BtJ5kuqHymyw%40mail.gmail.com.

[Shu-yu Guo]

On Fri, Jan 22, 2021 at 7:49 PM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Jan 22, 2021 at 5:15 PM Shu-yu Guo <s...@chromium.org> wrote:

Thanks for the answers, I have some inline response below.

I have another question. Historically there have been features that end up being very controversial with developers but nevertheless reached consensus. These features usually have prodigious amounts of discussion material from the developer community, much of which requires significant context to understand the nuance of, and much of which is noise. It will be a significant burden, if possible at all, to try to distill the public feedback into something digestible for API owner review. What kind of "primary source" material would the API owners be looking for in that case?

I suppose in these cases you'd say there is mixed positive/negative support. There is no choice in the table in the document I linked to for that, we should add it. I will take an action item to do so.

In these cases I'd suggest linking to representative comments in each direction.

 

On Fri, Jan 22, 2021 at 4:51 PM Chris Harrelson <chri...@chromium.org> wrote:

Hi Shu,

On Fri, Jan 22, 2021 at 2:30 PM Shu-yu Guo <s...@chromium.org> wrote:

Hi Chris and API owners,

What are your thoughts on proposals that have reached consensus in TC39? TC39 has many stakeholders, including both practitioners and browser vendors. Would having reached consensus at TC39 or similar consensus-seeking bodies with wide stakeholder representation (like the Wasm CG) count as having positive developer signal?

Good question. I don't think it's quite enough to expect TC39 to already take into account developer signals and rely upon that. For one thing, the blink-dev community not involved with TC39 wouldn't hear those signals, which keeps us from benefiting from their wisdom. For another, while I'm sure TC39 does a good job listening to everyone, other standards groups would make similar claims and then there'd be a slippery slope...

I think it's better for us all to get in the habit of communicating well with the community why we're doing stuff, which will in my personal experience help us learn better the purpose and potential of our own features, and also help others gain wisdom as well. It will also help to explain to other browser vendors why they should support a feature, and the same for developers who haven't encountered the feature yet.

Would it be easy enough to get evidence of these signals from the TC39 meeting minutes, or quick questions to practitioners along the way? I get it that it's a burden to have to go do that for a feature about to ship right now, but for future ones?

The TC39 plenary minutes are quite detailed (almost verbatim nowaday, we're experimenting with speech transcription), so if the signals are there, they should be easy to find.

Additionally there are non-plenary calls for specific audiences, like the Frameworks call where a certain audience's opinions are elicited. Minutes from that would have signals as well.

I'll refrain from stronger pushback for now and see how cumbersome this turns out to be in practice.

Ok thanks. I hope you don't need convincing that the API owners are reasonable and we'll always listen to feedback. :)

Oh I am perfectly convinced of the reasonableness. Different SDOs have very different operating norms, and in the web space TC39 is often the odd one out. This new requirement is also not unreasonable at all for a general policy. I'm just pushing back on the one-size-fits-all-ness.

[Chris Harrelson]

Hi, an update on this thread. Hearing no further objection to this policy change, the API owners last week decided to put it into effect, starting April 2, 2021.

To re-state: any Intent to Ship sent on or after April 2, 2021 will require developer signals. Note that this applies to all features, including ones that are already past some of the previous steps in the Intent process. (*)

There is also now a UI on chromestatus.com for these signals (see the fourth part):

Thanks,

Chris, on behalf of the API owners

(*) If you feel this timeline creates an undue difficulty for an existing feature that is almost done, please reach out to blink-api-owners-discuss or myself to see what we can do.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN-e9e9x3i%2Bs75JXeYenCQC3kc_XbbHbiy5_Pmty8r%3Dq1MOa%2Bg%40mail.gmail.com.

[Chris Harrelson]

Hi again!

Friendly reminder that this will start being enforced on April 2 (next Friday).

(Now's the time to rush all your intents out the door by April 1!)

April Fools jokes aside, please do reach out via instructions at https://goo.gle/developer-signals if you need help getting developer signals for your feature.

Chris, on behalf of the API owners