Elgato_dark/podman-desktop
1
0
Fork 0
mirror of https://github.com/podman-desktop/podman-desktop synced 2026-04-21 09:37:22 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 10

fix: usage data feedback

Browse source 
Responded to PR feedback:
- Changed setting location to use $HOME.
- Added location of anonymous id.
- Added info on how to import TelemetryLogger.
- Error object was originally meant to be pseudocode but it looks too much like an object, changed to typescript.

Signed-off-by: Tim deBoer <git@tdeboer.ca>
This commit is contained in:
Tim deBoer 2023-11-06 09:53:13 -05:00
parent 8928cd017b
commit e374db999c
1 changed files with 12 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
USAGE_DATA.md
View file

@ -6,8 +6,9 @@ Podman Desktop uses telemetry to collect anonymous usage data in order to identi
Users are prompted during first startup to accept or decline telemetry. This setting can be Users are prompted during first startup to accept or decline telemetry. This setting can be
changed at any time in Settings > Preferences > Telemetry. changed at any time in Settings > Preferences > Telemetry.
On disk this is stored in the `"telemetry.*"` keys within the settings file, On disk the setting is stored in the `"telemetry.*"` keys within the settings file,
at `~/.local/share/containers/podman-desktop/configuration/settings.json`. at `$HOME/.local/share/containers/podman-desktop/configuration/settings.json`. A generated anonymous id
is stored at `$HOME/.redhat/anonymousId`.
## What's included in the telemetry data ## What's included in the telemetry data
@ -32,17 +33,22 @@ Likewise, content like error messages often contains user-identifiable data like
### What to collect ### What to collect
Extensions can access the telemetry logger from the Podman Desktop API:
```
import { TelemetryLogger } from '@podman-desktop/api';
```
Telemetry should never be collected 'because we can', but because we want to see current behaviour in order to improve it. This means that we should only collect the minimal data in order to meet those goals, but conversely that we also collect enough to be able to act. For instance, collecting command pass/fail would tell us how often it failed, but not why it's failing in order to fix a bug or improve usability. Telemetry should never be collected 'because we can', but because we want to see current behaviour in order to improve it. This means that we should only collect the minimal data in order to meet those goals, but conversely that we also collect enough to be able to act. For instance, collecting command pass/fail would tell us how often it failed, but not why it's failing in order to fix a bug or improve usability.
When we capture information about commands and whether they succeed, they should be sent using logUsage() as a single event after an action completes, with optional error attributes. This makes it much easier to track the success rate and correlate failures with differences in environment or usage. logError() is typically used for independent or background errors. When we capture information about commands and whether they succeed, they should be sent using logUsage() as a single event after an action completes, with optional error attributes. This makes it much easier to track the success rate and correlate failures with differences in environment or usage. logError() is typically used for independent or background errors.
When calling logUsage() after an external commandline process or REST interface has failed, include an error object that contains the standard properties, e.g.: When calling logUsage() after an external commandline process or REST interface has failed, include an error object that contains the standard properties, e.g.:
``` ```ts
error { error {
message : string message: string,
statusCode : int - for HTTP calls statusCode: number, // for HTTP calls
exitCode : int - for processes exitCode: number, // for processes
... ...
} }
``` ```