--
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/CALgRrLnBcJ8-qGv1r61Cj9zqGVpttX2ij%2BPVrTwH7DSpb5GHNg%40mail.gmail.com.
Apologies for the delay responding to this... Busy couple of weeks :/Thanks for putting this doc together! I left a couple of comments, but I think my main issue with it is the following.I think that more often than not, Chromium engineers are not sure how to get a signal from developers and opt for neutral/no-signal without actually doing the outreach.That may change if we send them to chromiu...@chromium.org for help, but I'd then expect most of them to not do much more than to reach out, and expect a response that includes the signals acquired.In the past year we've seen ~190 related intents (I2S+I2E).I think we need to ask ourselves what would happen if this process would prove to be successful:
- Cost
- Web DevRel folks would then need to triage and provide feedback on O(200) intents a year, roughly 1 per working day
- If Twitter polls are used for that purpose, won't that result in crowd fatigue? ("ugh, another poll from @chromiumdev...")
- Benefit
- We would get significantly higher-quality signals regarding developers and their needs
- We may be able to avoid shipping some unnecessary APIs and put them through more scrutiny (through OTs, etc)
Maybe there's a middle-ground path with some more guidance on how Chromium engineers can do some of that work themselves, to make the above more sustainable.
As is, I'm concerned about the "cost" part (even if excited about the "benefits" part, if we can pull this off).Thoughts?
On Wed, Nov 11, 2020 at 12:34 PM 'Thomas Steiner' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:--(Friendly ping, since this was originally sent on US election day and may have been lost…)On Tue, Nov 3, 2020 at 10:57 AM Thomas Steiner <to...@google.com> wrote:Esteemed API Owners,Similar to the Signals from other Implementers in an Intent-to-Ship, I wanted to formalize the Signals from Web / Framework Developers (🆕.) The core contribution of this doc is to define:The rationale is to make the relevant section of ChromeStatus (screenshot below) more actionable, and to help DevRel with tangible interaction points to grow feature adoption.
- ① what exactly counts as support, with a special focus on…
- ② libraries that (potentially partly) already do what the feature proposes as a very strong positive signal.
To make this last point ② clearer, here is an example: the Screen Wake Lock API allows the screen to stay awake. The same functionality was implemented as a hack in NoSleep.js by tricking the browser into requesting a media wake lock for an invisible video that the library plays in the background. DevRel has PR'ed native Screen Wake Lock support into NoSleep.js, so upon the next update of the library its users will magically just use the new feature.For feature authors, identifying and finding such libraries as part of the process can thus—with the help of DevRel—be a good recipe for potentially gaining developer uptake by replicating the example above. It is well noted that not all features will be a good candidate for ②, but in such cases the added clarity of ① is hopefully still helpful in providing evidence of developer support.Looking forward to hearing your opinions.Cheers,Tom
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/CALgRrLnBcJ8-qGv1r61Cj9zqGVpttX2ij%2BPVrTwH7DSpb5GHNg%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/CALgRrL%3Djfyd%2B2HUkByS1_WN-gPJ3b_prvyVviRCQr%2B7NduG72A%40mail.gmail.com.
Bugs filed by another implementer are high quality, are important and should be prioritized
Best ways to detect developer pain:
Duplicate bugs
Survey results
Stack overflow results
Starring for crbug
We should collaborate on fixing main areas at the same time. Suggesting CSS Flexbox and CSS Grid, and communicating publicly about this, both to get good input from developers, and also make them aware this area is being prioritized
We should collaborate on new major features. Container queries seem to be a good one, and based on Mozilla resource constraints, Google can do some of the initial heavy lifting work
For me, I think the piece is DevRel should be involved in the critical initiatives and DevRel should be able to help get actionable feedback back to the engineering teams to assess the needs and perspectives of developers throughout the lifecycle of an API's development. For the API's that are not in the WP "critical initiatives" focus, then I would expect that Blink should have a consistent process that DevRel should help run (we have an OKR for that) that any team can use to gather feedback either at scale, or from a representative set of developers to help us justify the decisions that are being made in the design of the platform.
On Mon, Nov 23, 2020 at 11:26 AM Robert Nyman <ny...@google.com> wrote:Thanks for adding me, Tom!This is a really interesting area, and with DevSAT work we have been discussing this a lot in terms of survey results and data (MDN surveys and our quarterly ones) together with starring bugs in crbug. One more challen which has come up is Stack Overflow, which might be worth adding to the doc.
Tangentially, we (Chrome DevRel + Engineering) also met with Mozilla Engineering last week to discuss developer pain point signals – meeting notes.The main takeaways were:
Bugs filed by another implementer are high quality, are important and should be prioritized
Best ways to detect developer pain:
Duplicate bugs
Survey results
Stack overflow results
Starring for crbug
We should collaborate on fixing main areas at the same time. Suggesting CSS Flexbox and CSS Grid, and communicating publicly about this, both to get good input from developers, and also make them aware this area is being prioritized
We should collaborate on new major features. Container queries seem to be a good one, and based on Mozilla resource constraints, Google can do some of the initial heavy lifting work
Bugs filed by another implementer are high quality, are important and should be prioritized
This wasn't fully clear to me. Does it refer to the Edge comment that their "everyone can report bugs" feature results in low quality bugs?
Best ways to detect developer pain:
Duplicate bugs
Which is a signal also used by Apple.
Starring for crbug
It's a good signal, but also an easily "gameable" one. @Kent Tamura probably has more insights in how far this is actually a problem.
We should collaborate on new major features. Container queries seem to be a good one, and based on Mozilla resource constraints, Google can do some of the initial heavy lifting work
Would love to see us collabore as early as possible. And I think we do.
Bugs filed by another implementer are high quality, are important and should be prioritized
This wasn't fully clear to me. Does it refer to the Edge comment that their "everyone can report bugs" feature results in low quality bugs?Basically, both Chrome and Firefox Engineers agreed that bugs from other implementers were high quality.The Edge comment was a separate thing, namely if we lower the bar for reporting bugs, we also get lower overall quality and too much work triaging.
Best ways to detect developer pain:
Duplicate bugs
Which is a signal also used by Apple.Good point!It would be nice to have a list with commonalities across bug reports for engines for what are strong and good signals.
Starring for crbug
It's a good signal, but also an easily "gameable" one. @Kent Tamura probably has more insights in how far this is actually a problem.Yeah, that is a risk. For things raised in the MDN surveys as the biggest issues, we saw a strong correlation with star count.That said, itäs definitely worth exploring more, and also how we combine signals. E.g. dupes + starts + …
On Tue, Nov 24, 2020 at 7:44 PM Robert Nyman <ny...@google.com> wrote:
Bugs filed by another implementer are high quality, are important and should be prioritized
This wasn't fully clear to me. Does it refer to the Edge comment that their "everyone can report bugs" feature results in low quality bugs?Basically, both Chrome and Firefox Engineers agreed that bugs from other implementers were high quality.The Edge comment was a separate thing, namely if we lower the bar for reporting bugs, we also get lower overall quality and too much work triaging.
Best ways to detect developer pain:
Duplicate bugs
Which is a signal also used by Apple.Good point!It would be nice to have a list with commonalities across bug reports for engines for what are strong and good signals.
Starring for crbug
It's a good signal, but also an easily "gameable" one. @Kent Tamura probably has more insights in how far this is actually a problem.Yeah, that is a risk. For things raised in the MDN surveys as the biggest issues, we saw a strong correlation with star count.That said, itäs definitely worth exploring more, and also how we combine signals. E.g. dupes + starts + …If an issue in crbug.com is merged to another issue, the number of stars of the former issue is added to the number of stars of the latter issue. So we might not need to take a look at the number of dupes.The number of stars can be gameable, however I have never seen issues which have a huge number of stars but look unimportant.My rough impression is that:- 10+ stars: strong signal- 5+ stars: positive
The number of stars can be gameable, however I have never seen issues which have a huge number of stars but look unimportant.
My rough impression is that:
- 10+ stars: strong signal
- 5+ stars: positive
--
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/CAA1RLOF0HORXLBQ3rwyKo%2BCPc5%3DKLAcyQc5pVajhfqKq%3D739tw%40mail.gmail.com.
I'm supportive of asking intent owners to find signals from developers, and enumerating the kinds of signals we think are useful.
I also think it's reasonable to consider requiring such signals as part of shipping an API - i.e. show evidence that the API matters to developers. If we ship an API, we should be able to show that it has customers.
--
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/CALgRrLkCjTLZLo1kA9JaS3XtECW-_%2Byc%2BBKoubFqqfJeseFb2g%40mail.gmail.com.
For URLPattern I have been thinking about creating a short survey when the API is entering final dev trials and/or close to ship ready. This could give us a metric like "67% positive out of 542 responses" or something. It would of course suffer from selection bias of who chooses to fill out the survey, but might be a reasonable signal.
I'd make the document public, so anyone (even folks without a
@chromium.org) could read it.
In theory you could fill a bug at
https://github.com/GoogleChrome/chromium-dashboard/issues/ to get it
added into chromestatus UI.
Thought we haven't been lucky yet to get https://bit.ly/blink-signals
linked from there (see
https://github.com/GoogleChrome/chromium-dashboard/issues/1051). O:-)
And probably this new document should be linked from
https://bit.ly/blink-signals too, as there's a mention to web developers
signals.
I'm still not 100% clear on what non-Google Chromium contributors are to make of the Obtaining developer signals section. How are non-Google contributors supposed to get help from the Chrome Web DevRel team? Is there a mailing list they can use for that? Seems like it would be good to clarify that part.
Re adding to the official process: I'd like to discuss this at our weekly meeting this Thursday at noon PST. I think it's a good idea to add this to the process, but would like to have a brief in-person discussion first. Thomas, if you are able to and would like to attend, I can add you to this instance.
Assuming we make the decision on Thursday, an API owner should announce the result on blink-dev and a date after which this will be enforced, and also to collect any remaining feedback from the community.
Done. Your agenda item will be first in line.
--
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/CALgRrL%3DVxO2wZ5CQYteJAj3GmJQY10z6qVqiH1eSb6-chnW-rg%40mail.gmail.com.
This is a great addition to the process, thank you!
Wondering if it's worth calling out what a high quality signal looks like as opposed to a drive by twitter response, or ad hoc twitter polls which could have arbitrary signal-to-noise ratio.
I'd say a high quality signal would be interest from a developer in using the proposed feature in a production website or links to libraries showing existing usage in userland and high star count for bug fixes.
Also I assume "framework" is a proxy for wide adoption, if so considering the popularity of the framework would help.
Also I recognize this is an addition to an already tedious process for web platform engineers, and I'd love to offer help -- my team works on a regular basis with a number of production sites as well as popular frameworks.I'll follow up to see how we could concretely help at least Google engineers who are implementing standards.