Feb 10 5pm US Eastern: Thanks for the lively discussion everyone. It has given me plenty to think about. We are starting to go in circles, and actually new comments are increasingly rare, so I've locked this to give everyone their weekend back. Thanks again.
If anyone feels like there's something important that wasn't said in these 506 comments, please feel free to email me at email@example.com.
Feb 26 The current plan is to use some form of opt-in to collect telemetry.
How do software developers understand which parts of their software are being used and whether they are performing as expected? The modern answer is telemetry, which means software sending data to answer those questions back to a collection server.
I believe that open-source software projects need to explore new telemetry designs that help developers get the information they need to work efficiently and effectively, without collecting invasive traces of detailed user activity.
I have written a short series of blog posts about one such design, which I call transparent telemetry, because it collects as little as possible (kilobytes per year from each installation) and then publishes every bit that it collects, for public inspection and analysis.
I’d like to explore using transparent telemetry, or a system like it, in the Go toolchain, which I hope will help Go project developers and users alike. To be clear, I am only suggesting that the instrumentation be added to the Go command-line tools written and distributed by the Go team, such as the
Transparent telemetry has the following key properties:
Beta Was this translation helpful? Give feedback.