"Blink component" in I2* emails?

[Johnny Stenback]

Hey API owners,

In a recent discussion around the launch process and tooling in chromestatus.com the question came of whether there's any meaningful value in asking feature owners what Blink component a feature belongs to. There's a non-trivial cost around that particular field and maintaining the list of components etc (for historical reasons), and it's not at all clear what the value of tracking that information per feature is. The conclusion amongst those in the room was that it'd be a net win to remove that field. We do show that component in I2S emails etc, so one outstanding question was whether or not API owners care about that field being in the I2S etc emails?

Thanks,

Johnny

- jstenback (he/him)

[Ian Kilpatrick]

One thing that comes up occasionally that this field facilitates with is what component bugs should be triaged into, and if the team responsible for that feature is set up to triage (and address) incoming bugs.

For example there have been cases of "generic" non-Blink components being used for this purpose, and/or new components which should be explicitly created for a few features. This field helps ensure features have a plan for incoming bugs.

Ian

--
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/CACZRgz52hBzviNC9jpi4WNp_rzcykrjzJfC67TACm1oEjPKoRA%40mail.gmail.com.

[Jeffrey Yasskin]

I've used this field to help guess what team owns a feature, especially after its original owners have transferred away. The Blink component isn't the best way to infer that, but it's what we've had.

Jeffrey

On Mon, Dec 12, 2022 at 11:28 AM 'Johnny Stenback' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

--

[Rick Byers]

Yeah I don't think API owners rely on this at all. But I think the intention was to make it easy for web developers to know how to get feedback to the feature authors. Since we have the Blink bug triage fallback I don't think this is a huge issue, but in principal I like the idea that anytime we ship a feature we have a clear "find known issues and file new issues here" signal to web developers which is most likely to minimize response latency. +Paul Kinlan who may have thoughts from a DevRel perspective. In general I think it's important that we emphasize to feature developers that we expect them to be responsive to customer feedback on their API.

Rick

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

[Thomas Steiner]

Not Paul, but echoing an earlier comment that having the component recorded is a huge help for DevRel on the ground for pre-triaging incoming developer feedback in the form of bugs, and filing bugs ourselves, including getting an overview of what’s already been filed and is being worked on. So huge +1 for keeping this piece of information. 

Cheers,

Tom

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

--

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

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

----- BEGIN PGP SIGNATURE -----

Version: GnuPG v2.3.4 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/

----- END PGP SIGNATURE -----

[Paul Kinlan]

+1 to what Thomas and Rick said.  I also use it to track hotspot areas and who devrel owners should be (http://go/blink2devrel - although it's currently out of data, so maybe highlights a similar issue to what Johnny said)

One thing to add on top of what Rick said about "find known issues and file new issues here" - I am not sure that it's clear to external developers how they should label the bugs that they raise and frequently we help them find that right label. What I will say is that I think that it is incredibly useful for developers to know all the issues around an area, who to potentially speak to and have confidence that it will get seen by the feature owner (and actioned in some way), whether that's a component or a way to group bugs around feature areas, if we can improve the perception about our responsiveness and transparency about our work, I am all for it.