Anonymous user behaviour data collection #269
Conversation
|
action items from 15/06 community meeting:
|
new/telemetry.md
Outdated
| filter more aggressively if required. | ||
|
|
||
| For example, knife may report that a `-P` option was invoked, but will never | ||
| collect the password parameter that was passed to that option. |
There was a problem hiding this comment.
maybe they should also only collect data on successful commands? unsuccessful commands are more likely to have accidentally typed passwords on them and such (knife bootstrap -Passw0rd1)
There was a problem hiding this comment.
well, we want to know about people running unsuccessful commands, but maybe in that case we should just collect which command was tried.
|
I've been a casual Chef user and a booster of the ecosystem for several years. I understand the desire to get telemetry on use of the products and the frustration with the poor uptake on opt-in mechanisms. At the same time, moving to an opt-out stance is a third rail issue for me, my organizations, and the clients I serve. I strongly urge Chef Co. to reconsider this RFC. If adopted, I will be forced to take a serious look at removing Chef products from my tool chain as I find such behavior completely unacceptable. It's good to know that Habitat already has this turned on by default. I had been intending to delve into that product but will now strike that off my list. Again, the desire for this information is certainly understood and I ascribe no ill intentions to anyone. Simply not a behavior I find acceptable in any of the software I use or support. |
|
Closing the loop on a Slack conversation, my objection is to any software that collects user behavior without my explicit, opt-in consent. As an open-source user and contributor, collecting user behavior without consent changes the implicit contract in a way with which I am not comfortable. Arguments that other software or orgs are doing similar items are not germane. I care about Chef and what Chef does here. It's clear that my opinion is not a vocal one. I suspect, but have no data to prove, that there are many other casual users of the chef ecosystem of products, that also object to such a change. Consider this a voice of those users. Again, adopting this change will cause me to give pause to recommending Chef to clients large and small and certainly reduce the efforts I put into supporting the Chef ecosystem in general. |
Data collection is not enabled by default in Habitat. See https://github.com/habitat-sh/habitat/blob/master/components/hab/src/analytics.rs |
|
This seems solid to me, personally. |
|
Further discussion on opting in/out: |
|
Telemetry is "nice to have", and not in any way required to release and iterate on quality software. Worse, as an opt-out default, it ends up creating an anti-demographic cohort, giving the most weight to users who care the least about their privacy and how their data is used. Explicit, opt-in consent is a moral requirement in my opinion. Anything less is explicitly anti-user. I would hate for Chef to become Yet Another piece of hostile software designed to run at the developer's convenience rather than the users. |
|
I could have used it here to understand the impact of removing the Could also use it here, to give information on how many people are still using Just two examples from the past couple months The whole Chef-13 release was also a pile of deprecations. |
|
I am certainly in favor of explicit opt-in strategy for data collection especially on open source software. |
|
approved @chef/rfc-editors |
Signed-off-by: Thom May <thom@chef.io>
|
Accepting, assigning RFC 094 |
In order to provide greater insight into how our Chef users interact with Chef tools, this RFC introduces a framework for defining the policies for the anonymous collection (sharing), storage, and deletion of product usage data that can be applied to any Chef project.