We took a survey of your impressions of our process and tooling back in February, and I wanted to share the results. This survey was an iteration of a survey conducted in early 2021; where interesting, we’ll compare responses. We only got 22 responses this year, down from 62 last year, so the results are more suggestive than statistically significant.
81% of respondents work on Chromium full-time, down from 95% last year.
Of the 20 people who work on Chromium as part of their jobs, 4 people identified themselves as working for non-Google companies, about the same as the 30% last year. Unlike last year, nobody identified themself as from Microsoft, only Opera and Intel.
81% develop features.
59% participate in a standards body.
40% are API owners or decide what features to enable in a Chromium-based browser, which overrepresents high-level decision-makers in the survey results.
The people who replied feel better about their understanding of the process than last year:
Most of the more-detailed questions about understanding follow this pattern, with some remaining confusion about how to gather Web Developer Signals, using feedback from Origin Trials, and how the Chromium process interacts with processes within standards bodies. This is better than the understanding last year, although this result could be skewed by the higher proportion of API owners and decision-makers in the responses.
Respondents reported that it's hard to maintain features in Chrome Status, partly because the UI is confusing and not tailored to all of the types of features that people need to create and maintain. This contributes to the information in Chrome Status being out of date. Developers also complained that issues they file don't get fixed promptly.
Many of the respondents are discouraged about TAG review and review by other browser engines. TAG review is considered slow and unhelpful, and one developer said they sometimes feel like a punching bag for other vendors.
Googlers appreciated fast build speeds and Goma but folks complained about flaky tests and CQ reliability. There were some complaints that the infrastructure teams have launched new versions of some tools without addressing the bugs in them.
I've also collected more details and people's text responses in this document.
Chromium/Chrome Developer Relations (DevRel) can—no surprise—help with reaching developers. The team can be contacted via chromiu...@chromium.org. For external-facing developer outreach, DevRel has access to the official @ChromiumDev Twitter account—well noting that this may introduce follower bias. DevRel can signal-boost or create polls, and ask people to chime in on conversations happening on GitHub, Discourse, and elsewhere. For more in-depth surveys, the Chrome team is working with C SPACE to build a dedicated community of about 600 Web developers from a range of backgrounds, experiences, skill sets, and industries who will provide direct feedback to questions that you come up with. The Chrome team also works with a group of volunteer Google Developer Experts (filter the map for “Web Technologies”) who may be able to provide expert feedback. Contact DevRel via the alias above if any of this is of interest and we will set you up. In all cases, a reasonable amount of time should be allowed for responses to this process.
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/CANh-dXkk%2Bcm%3Dz940TAOAau%2BpJ0GpXRLFvmHP5HWWBjr4ghEJoQ%40mail.gmail.com.
Note that your quote is from last year's summary
38 clicks in 90 days does seem low, given that we had ~50 intents to ship over that time. Picking 2 arbitrarily, neither hidden=until-found nor MediaCapabilities API has developer signals, but the API owners only complained about it (and pointed to goo.gle/developer-signals) for the latter.
I suspect other people on this list will have better ideas about what would help them understand developer signals better.