-
Notifications
You must be signed in to change notification settings - Fork 21
Telemetry Initiative
To collect useful data so that we can make better-informed decisions about what should go into (or be removed from) backdrop core.
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 short term in an existing database on BackdropCMS.org. We would NOT store data long term, rather use the data to update cumulative statistics. In other words, we would not keep all of the data for each site, rather use the data to update the totals for each question and then delete the data. (Is it possible that we MIGHT keep the data for each site for a short time, but that is undecided. It seems unlikely that we would store all the weekly data from each site for the long term). Somewhere on their site each user would have the ability to uncheck a box that says something to the effect of "Would you like to send anonymous data to backdropcms.org to help inform future product development?" Unchecking this box would effectively disable the telemetry module.
To the extent that data is stored in the database at all, it would be anonymous. At most linked to a unique hash, but never with specific site information that could be used to identify the source of the data.
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.
- The original TELEMETRY issue in the core issue queue.
- Google Doc from Backdrop LIVE (Oct 17th, 2020)
- https://stats.civicrm.org/?tab=technology
- [] Create a telemetry module for Backdrop CMS Core. See PR #3379
- [] Prepare BackdropCMS to accept this data (See: #285) - This has been started with a PR for the Project Module - PR #50
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
- Are users able to login to the site?
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 #3168. 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.
We expect to send the data on a weekly basis.
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.
- Being totally transparent about exactly what we are collecting and how it is being used.
- With opt in language similar to this: Would you like to send anonymous data to backdropcms.org to help inform future product development?
At this time, I believe that there are two options for this.
- 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.
- 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.
There has been some discussion about how to make this feature available for use by contrib modules. Initially, we would probably prefer to limit collection of data to core modules. However, there are ideas/discussions about using it for contrib as well.
- hook_telemetry_data - https://github.com/backdrop/backdrop-issues/issues/285#issuecomment-711465712
- Allowlist for contrib modules - https://github.com/backdrop/backdrop-issues/issues/285#issuecomment-711498076