2 ms·
Absolutely agreed with the second point. I’m not sure I agree with the first though. At least not that that’s the main reason telemetry is desired from product
by tilne 3y ago
Absolutely agreed with the second point. I’m not sure I agree with the first though. At least not that that’s the main reason telemetry is desired from product teams. (Though obviously telemetry does provide fodder for that type of stupidity for sure.)
To give a concrete example from my past experience, I used to work on a product that essentially knitted a bunch of services from a major cloud provider together to provide a user experience comparable to traditional HPC clusters. We never included telemetry, but we always wanted to in order to gain insight into how many compute queues people were using, how many VMs were in each of them, how many jobs were run over a certain amount of time, how many VMs those jobs ran across, etc. The sole reason we wanted this information was because the configuration exposed for this product was extremely complex, and we wanted to put layers on top of it to more easily enable the most common use cases.
Is this not a legitimate reason to collect telemetry? Is the concern that, even though the dev team wanted the data for legitimate purposes, eventually bad actors will use the capability to start collecting data for more nefarious purposes?
Edit: I see you amended the original to include a statement about opt-in opinions. What do you mean by that?
- pydry 3y agoMy edited statement wasnt directed at you (Ive only just read your reply) but it does indirectly answer your question. What I mean is that you survey your users via your app on, say, the config page and ask them if they think its too complex and if it would benefit from layers or whatever and always let then enter an optional opinion when you do.