Spike: collect local telemetry

[suzannehamilton]

The CLI does not collect telemetry from users, but it already has some of the configuration to do this, because of the code that was merged from job-runner.

We expect that collecting CLI telemetry would help us to improve the whole OS workflow (including ehrQL), because it would help us understand what kinds of errors users see when running local jobs. It would also give us some insight into how users move between running local jobs and running jobs in the secure environment.

There's more work we need to do before we can collect telemetry in general, such as:

• Showing users our privacy policy and allowing them to opt in or out
• Designing a way to securely send telemetry from users' machines to Honeycomb without exposing Honeycomb API keys
• Finding a way of tagging telemetry with user, repo and/or OS project information to make it easier to analyse

To decide whether it's worth doing that work, we can do this spike: ask for one or two volunteers from the research team to set up local telemetry manually (with our help). They should be people who are actively developing code and running it locally, so we can collect some data. After some time (maybe a month?) we can review the telemetry to see whether it would be interesting to do the work to roll it out more widely.

[suzannehamilton]

Will we get ehrQL errors? We'll get some of them, but not a lot of the interesting ones.

So we may have to tweak the telemetry that's collected in the CLI - but only essential changes, to keep this a small spike.