You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want to use telemetry to answer questions about which settings are being customized by our users. This signal can be useful in a number of ways, for example to prioritize improvements to various optional features, suggest that certain configuration can be deprecated, or indicate that certain optional features are not working well (if they are frequently disabled).
A few considerations:
For some settings, we just want to record whether they are used (e.g. "buildFlags").
For other settings, we want to bucket the actual setting values (e.g. "staticcheck:true")
For yet other settings, there are logical sub-settings which may themselves have logical bucketing (e.g. "analyses/deprecated:false").
Some settings can be set in multiple ways (usually in a transitional period when an old setting name is deprecated).
Therefore, this instrumentation will necessarily be customized to each individual setting.
The following schema seems pretty natural: gopls/setting/<setting>[/<subsetting>][:buckets]
Notably, we only record the settings that are actually explicitly set by the user. We don't record the effective values of all settings. I briefly considered recording the effective values of each setting, but that is a lossy projection: it loses information about which settings are actually being explicitly set, and we may want to see when users are customizing a setting, even if they are customizing it to the default value.
This issue tracks only the addition of this instrumentation. Separate telemetry proposals must be filed for any collection of this data from users who have opted in to telemetry.
gopherbot
added
Tools
This label describes issues relating to any tools in the x/tools repository.
gopls
Issues related to the Go language server, gopls.
labels
Jan 15, 2025
We want to use telemetry to answer questions about which settings are being customized by our users. This signal can be useful in a number of ways, for example to prioritize improvements to various optional features, suggest that certain configuration can be deprecated, or indicate that certain optional features are not working well (if they are frequently disabled).
A few considerations:
Therefore, this instrumentation will necessarily be customized to each individual setting.
The following schema seems pretty natural:
gopls/setting/<setting>[/<subsetting>][:buckets]
For example, given the following configuration
we'd record the following counts:
Notably, we only record the settings that are actually explicitly set by the user. We don't record the effective values of all settings. I briefly considered recording the effective values of each setting, but that is a lossy projection: it loses information about which settings are actually being explicitly set, and we may want to see when users are customizing a setting, even if they are customizing it to the default value.
This issue tracks only the addition of this instrumentation. Separate telemetry proposals must be filed for any collection of this data from users who have opted in to telemetry.
CC @adonovan
The text was updated successfully, but these errors were encountered: