Hacker News Reader

Hacker News

Comment by zabil | Hacker News Reader

Full thread

zabil

We are struggling, philosophically, with anti telemetry posts (like this one).

We are turning on telemetry in the next release for our open source tool. https://github.com/getgauge/gauge

We are small team with limited resources.

In our tool, it's easy to turn telemetry off, inspect what data is sent and the data collected is public.

The data "really" helps to make the tool better and an opt-in skews the data.

We've published an blog post https://blog.getgauge.io/why-we-collect-data-b19df366b677 and will put it up in the release notes and the download section.

What else can be done so that users don't blow up?

View on HN

Let's just be clear that it's entirely OK to add telemetry to your code. The objection here from most of us I suspect is that it is on by default. If you package a tool so it does an unattended installation in some way i.e. via a package manager etc, the default state of the code should be opt-out of telemetry. If you have a GUI installer, ask the user if they want it and outline the benefits and what you collect.

If you get an uptake of say 5-10%, if that's worth it then problem solved. If it's not then don't bother adding telemetry to start with.

But before you do this, you have to ask the question: how did the software industry get by before the sudden rise of telemetry? It engaged the customer.

I think a lot of cases it is used it is used as a substitute for engaging the customer.

Indeed. Though on-by-default telemetry gets a different set of data than engaging with the customer.

If adding telemetry is faster and easier than engaging with the customer, then you'll see projects that add telemetry that wouldn't otherwise have the bandwidth to engage with the customer.

In general, I think the best way to go is to ask in the installer or initial setup, whether you want to send telemetry, and have a sane default according to whether you gather potentially personal information (location? personal, commands run (without args), not personal).

Example Prompt: Send telemetry (commands used, version) (y/n)[y]:

We've experimented asking users on install or initial setup. But most of the time our tool runs in non interactive environments e.g. on a CI/CD set up (install and execution).

An additional flag for non-interactive installs can solve the problem, but that's a broken setup experience, someone has to look up the documentation after a failure to install.

Turning it off by default in case of a CI/CD setup means losing most of the data.

If you're setting up automated non-interactive installs, your job is to check for install failures and consult the documentation; I know that's part of my job.

I'd recommend a required installer flag forcing the user to make a decision, but I'm a user who generally leaves telemetry on.

Thanks for all the suggestions.

Here's what we are doing next release (out this week)

* Ask if the user wants to opt out in the graphical installers.

* Print a message after non-graphical installs about data collection and link to documentation on how to turn it off.

The minimum should be a clearly presented option to turn off telemetry either during install or at first startup.

Just a mere suggestion: you may look into how it's done in yeoman (https://github.com/dotnet/cli/issues/3093#issuecomment-22034...) and read this https://github.com/dotnet/cli/issues/3093 as there's lots of user input there.

Reply on news.ycombinator.com