New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Anonymous user behaviour data collection #269

Merged
merged 2 commits into from Oct 8, 2017

Conversation

Projects
None yet
8 participants
@thommay
Copy link
Collaborator

thommay commented Jun 15, 2017

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.

@thommay

This comment has been minimized.

Copy link
Collaborator Author

thommay commented Jun 15, 2017

action items from 15/06 community meeting:

  • add back the language about public sharing
  • explicitly disallow chef-client
  • collect Chef and other tool versions
  • allow tools to detail what they're collecting
  • change "and it is expected that each app would create a follow up RFC that details individual behaviour" to be "each app MUST create a follow up RFC ..."
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.

This comment has been minimized.

@lamont-granquist

lamont-granquist Jun 15, 2017

Contributor

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)

This comment has been minimized.

@thommay

thommay Jun 22, 2017

Author Collaborator

well, we want to know about people running unsuccessful commands, but maybe in that case we should just collect which command was tried.

@davidski

This comment has been minimized.

Copy link

davidski commented Jul 16, 2017

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.

@davidski

This comment has been minimized.

Copy link

davidski commented Jul 16, 2017

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.

@smith

This comment has been minimized.

Copy link

smith commented Jul 16, 2017

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.

Data collection is not enabled by default in Habitat. See https://github.com/habitat-sh/habitat/blob/master/components/hab/src/analytics.rs

@stormerider

This comment has been minimized.

Copy link

stormerider commented Jul 27, 2017

This seems solid to me, personally.

@thommay

This comment has been minimized.

Copy link
Collaborator Author

thommay commented Sep 7, 2017

Further discussion on opting in/out:
if there's no sentinel flag and we have a terminal, ask the question and be hard yes or hard no. if we don't have a terminal, leave it nil, which right now means "disabled", but in future and given warning and notification may change to "enabled"

@metaxis

This comment has been minimized.

Copy link
Member

metaxis commented Sep 8, 2017

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.

@lamont-granquist

This comment has been minimized.

Copy link
Contributor

lamont-granquist commented Sep 8, 2017

I could have used it here to understand the impact of removing the berks test * set of commands:

berkshelf/berkshelf#1702

Could also use it here, to give information on how many people are still using berks cookbook/berks init instead of chefdk and which version of berks they're on:

berkshelf/berkshelf#1729

Just two examples from the past couple months

The whole Chef-13 release was also a pile of deprecations.

@ldesiqueira

This comment has been minimized.

Copy link

ldesiqueira commented Sep 14, 2017

I am certainly in favor of explicit opt-in strategy for data collection especially on open source software.

@thommay

This comment has been minimized.

Copy link
Collaborator Author

thommay commented Sep 14, 2017

approved @chef/rfc-editors

Thom May and others added some commits Jun 6, 2017

@adamleff adamleff force-pushed the tm/telemetry branch from 253b006 to bb668fd Oct 8, 2017

@adamleff

This comment has been minimized.

Copy link
Contributor

adamleff commented Oct 8, 2017

Accepting, assigning RFC 094

@adamleff adamleff merged commit a702e5f into master Oct 8, 2017

@adamleff adamleff deleted the tm/telemetry branch Oct 8, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment