Open baywet opened 1 year ago
You can follow our journey here while we're building the specs for this capability #4063.
Slight update here. The spec of what to collect and how to opt out is pretty much ready. We have received the feedback it might alienate some users and are reviewing our options now. @sebastienlevert to confirm the plans at a later time, no work to be done for now.
We'll keep this issue open for some time. But as of today, our decision is to rely on the telemetry already provided by the VS Code implementation that is all guided by the VS Code telemetry guidelines.
Follow up to #2933
The current telemetry implemented in the vscode extension gives us some level of understanding of usage and patterns. We should refine this and extend it to the CLI itself since the extension is only a small portion of our audience. The dotnet CLI is most likely how we should model it.
The telemetry should print a message on first call for the version, so people are aware anonymized data is being collected and have an option to opt out. This message should not be displayed in CI (check the environment variable) as we might want to disable the telemetry in CI scenarios to avoid "noise".
The extension should probably pass a session id to the CLI through the RPS service so we can track dependencies end to end in case of crashes.
Pointers to the dotnet CLI implementation. sdk/src/Cli/dotnet/Telemetry/Telemetry.cs at main · dotnet/sdk · GitHub the metrics they collect sdk/src/Cli/dotnet/Telemetry/TelemetryCommonProperties.cs at main · dotnet/sdk · GitHub they use some filters for some commands sdk/src/Cli/dotnet/Telemetry/TelemetryFilter.cs at main · dotnet/sdk · GitHub sdk/src/Cli/dotnet/Telemetry/TelemetryFilter.cs at 72b4ede487d5e03fa58fb0df27ad2188e261242c · dotnet/sdk · GitHub
Before we move on to the implementation, we need to refine what should be collected, what shouldn't, and what questions are we trying to answer