x/telemetry/config: collect gopls/telemetryprompt/accepted #68770
Comments
|
Related Issues and Documentation
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.) |
|
It occurred to me that because we have a conservative cutoff, we won't ever upload the counter file for the day that telemetry is enabled: we only upload counter files that do not overlap with any period of time when telemetry uploading was not enabled. Therefore, I think gopls should record at every startup whether the prompt was accepted. Theoretically, we could also record other prompt outcomes: some users may decline the prompt but enable telemetry via other means. Putting this in the [email protected] milestone to address the collection issue. |
cagedmantis
added
the
NeedsInvestigation
|
Change https://go.dev/cl/603936 mentions this issue: |
|
Change https://go.dev/cl/607758 mentions this issue: |
Increment the gopls/telemetryprompt/accepted counter every time we read the prompt file, so that we can actually use the resulting data. We don't upload any counter files that overlap with periods of time when telemetry uploading was not enabled, so with the previous model of only incrementing the counter at the moment the prompt was accepted, we will never upload the counter file into which the acceptance is recorded. With the new model, the counter will give us a sense of what fraction of telemetry participants opted-in as a result of the prompt. For golang/go#68770 Change-Id: I8890c73b5bfa19023bb24fd156bcaa9eb46295ad Reviewed-on: https://go-review.googlesource.com/c/tools/+/607758 Reviewed-by: Hyang-Ah Hana Kim <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
|
Change https://go.dev/cl/609135 mentions this issue: |
…ptance counter for each session Increment the gopls/telemetryprompt/accepted counter every time we read the prompt file, so that we can actually use the resulting data. We don't upload any counter files that overlap with periods of time when telemetry uploading was not enabled, so with the previous model of only incrementing the counter at the moment the prompt was accepted, we will never upload the counter file into which the acceptance is recorded. With the new model, the counter will give us a sense of what fraction of telemetry participants opted-in as a result of the prompt. For golang/go#68770 Change-Id: I8890c73b5bfa19023bb24fd156bcaa9eb46295ad Reviewed-on: https://go-review.googlesource.com/c/tools/+/607758 Reviewed-by: Hyang-Ah Hana Kim <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> (cherry picked from commit 594cdab) Reviewed-on: https://go-review.googlesource.com/c/tools/+/609135
Changes in this release
This release updates the golang.org/x/telemetry dependency to pick
up fixes for the following bugs:
golang/go#68946: unnecessary downloading of the golang.org/x/telemetry/config module
golang/go#68358: a potential crash on Windows when the telemetry counter file is extended
golang/go#68311: a potential hanging process if the telemetry file is truncated
Additionally, this release changes the gopls/telemetryprompt/accepted
counter to be recorded each time the prompt state is checked
(golang/go#68770).
None of these issues were particularly urgent, but we also wanted
to make a gopls release to exercise our recently added release
automation (golang/go#57643).
Summary
From gopls, we ask a select fraction of users to enable telemetry via an LSP prompt (a showMessageRequest dialog). Starting in [email protected], we record a gopls/telemetryprompt/accepted counter when users accept the prompt.
By collecting this counter, we can estimate the fraction of new telemetry participants that are coming from the prompt, which will help us evaluate the efficacy of the prompt itself.
Of course, we cannot know how many users decline the prompt.
Proposed Config Change
https://go.dev/cl/603936
The text was updated successfully, but these errors were encountered: