Authors: tomac@google.com, you?
Contributors: rego@igalia.com, yoavweiss@google.com, nyman@google.com, chrishtr@google.com
Short link: https://goo.gle/developer-signals
TL;DR: Try searching for developers positively mentioning your feature on Twitter (via Twitter's own search if you have an account [example], or via Google Search if you don't [example]). Proceed similarly on StackOverflow, GitHub, or perform a generic Web search (hint: append the term "blog" to your keywords). If this doesn't reveal useful signals, see Obtaining developer feedback below.
Every shipment requires Web / Framework developer views as part of the “Interoperability and Compatibility” subsection. Obtaining this signal is recommended for dev trials. For example, such a list for a hypothetical feature might read:
Web / Framework developer views: Positive (<link to Twitter poll>, <link to library that implements the feature in question>, <link to GitHub thread comment>)
These signals are reported for the purpose of giving an as clear as possible indication of the views of those developers as a proxy for "all" developers. Other Implementers Signal is yet another signal separate from the Web / Framework Developers Signal, and is not less important. As with other signals, the Web / Framework Developers Signal is only one input into the intent-to-ship process to take into consideration, and is neither a veto nor an implicit approval to ship.
If obtaining a Web / Framework Developers Signal is skipped or incomplete and N/A or No Signal is reported, it should be reported why. Reasons why can include:
Signal | Required evidence |
No Signal | Link to outreach attempts that remained unanswered. This is different from N/A. |
Positive | There is evidence of publicly linkable positive statements of support from developers or framework authors not associated with or not speaking on behalf of a browser vendor:
|
Mixed | There are signals that point in both positive and negative directions. Link to representative examples of each. This situation can happen if there is some amount of developer disagreement or controversy regarding a feature. In such cases, also add explanatory text about the reasoning for how the negative feedback is outweighed by the positive, and how the feature design mitigates the legitimate concerns represented by the negative feedback. |
Neutral / Negative | There is evidence of publicly linkable neutral / negative statements of support from developers or framework authors not associated with or not speaking on behalf of a browser vendor:
In such cases, also add explanatory text about the reasoning for how the feature design mitigates the legitimate concerns represented by the negative feedback. |
N/A | Indication of why a Web / Framework Developers Signal is not needed in this case and no outreach attempt was made. This is different from No Signal. |
Chromium/Chrome Developer Relations (DevRel) can—no surprise—help with reaching developers. The team can be contacted via chromium-devrel@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.
[1] Anecdotal evidence shows that 10+ stars can be counted as a strong signal and 5+ stars as a positive signal.