Skip to content

Telemetry Initiative

Tim Erickson edited this page Oct 18, 2020 · 15 revisions

Goal:

To collect useful data so that we can make better-informed decisions about what should go into (or be removed from) backdrop core.

Story (summary):

Every Backdrop CMS site would come with a telemetry module that is enabled by default on installation. Users would be informed that the purpose of the telemetry module is to send specific site data to BackdropCMS.org on a weekly basis and that they can prevent this transmission by disabling the telemetry module. The status page of every site would include information about whether or not the telemetry module is enabled and would link to a page on BackdropCMS.org with information about exactly what information is being shared and why.

The Telemetry module would send information to BackdropCMS.org using JSON. BackdropCMS.org would receive the data and store it in an existing database on BackdropCMS.org. Initially, the MVP version the module would send data on the following: PHP Version, MySQL version, and Webserver information. Future versions of the module would include additional information (see below).

We would need to build another module for BackdropCMS.org to expose the data in a format that MIGHT look like this.

Resources:

Things to do:

  • [] Create a telemetry module for Backdrop CMS Core
  • [] Prepare BackdropCMS to accept this data

FAQ:

What data do we want to collect

MVP

  • PHP Version
  • MySQL Version
  • Webserver and Version

Other options

  • which core modules are enabled
  • are clean URLs enabled?
  • which core layouts are in use?
  • which core module field types are in use?
  • which contrib (sub)modules (not projects) are in use?
  • which color module color palettes in use?
  • how many roles are in use (and their names?)
  • how many sites are using revisions?
  • which permissions are added to editor role
  • (problematic - need to think about implications of it)
  • PHP version (needed for #3490 and #719)
  • Server OS - needed for these
  • Multisite or not (needed for #3206)
  • Name of Install profile in use (needed for #3205)
  • Number of block displays vs page displays for views (needed for #2978)
  • Sticky admin bar setting (needed for #788)
  • User role names (needed for #1285)
  • Number of active themes (needed for #131)
  • Site size metrics (number of user accounts, number of nodes, number of managed files etc.)
  • Whether the site was a previous D6/7 upgrade
  • enabled modules & sub-modules (not just packages) d.o issue 1 | d.o issue2 | d.o issue 3 Needed for the following:
  • Contextual links module: #1409
  • Contact module: #3023

When will this data be collected/shared?

The original idea was that data would be sent when checking for updates. However, current thinking seems to be moving in this directory.

  • Checking for updates is no longer option. It is just something that we automatically do on every site.
  • At the time a site is checking for updates, it also pass along telemetry data to BackdropCMS.org IF the telemetry module is enabled. Users would be able to prevent the sharing of data by disabling the telemetry module in core.

Are we collecting data all the time?

We expect to send the data on a weekly basis.

Where do we want to collect the data.

Options include:

  • BackdropCMS.org database
  • Separate MySQL database
  • Solr database
  • Elasticsearch

The current thinking is that we would just start storing this data in our existing BackdropCMS.org database. Mostly, because of simplicity and to reduce the need to have someone with special skills available to manage this. We are open to other options, but based upon currently available skills and resources, the current BackdropCMS.org database seems to make sense.

How do we manage data responsibly and with consent?

  1. Being totally transparent about exactly what we are collecting and how it is being used.
  2. With opt in language similar to this: Would you like to send anonymous data to backdropcms.org to help inform future product development?

When and how would a user disable the telemetry module?

At this time, I believe that there are two options for this.

  1. That during the installation process users are offered an opportunity to disable telemetry (not install the module). Similar to how we currently provide users the option to disable checking for updates.
  2. Another line of thinking is that for the purposes of making installation as quick and easy as possible, we NOT ask this question during installation, but after installation provide them with information about telemetry and how to disable it.

Can this be used for contrib as well

No, we do not expect to make it possible for contrib projects to collect data using this process. At least, not initially. This is something that can be considered in the future.

How does Wordpress do this?

https://wordpress.org/about/stats/

Other examples