Moving project telemetry reporting from the update module into core

Created on 21 May 2024, 11 months ago

Problem/Motivation

The update module (packaged with core) provides a lot of functionality:

  • Reports interface to view a list of modules and themes that are out of date
  • Email notifications when there are updates available
  • Update individual modules and themes by uploading a file via the UI
  • Report usage metrics (telemetry) of installed modules and themes back to Drupal.org

For people that run a large number of sites, especially those that share a common codebase (very common in Higher Ed and Government), it's very common to NOT enable this module, because none of the functionality is needed. As a result, Drupal.org misses out on receiving a lot of telemetry data because it's bundled in this with this module.

Proposed resolution

Separate out the telemetry reporting from the update module and instead bring it into core. I briefly scanned thru the code and didn't see an obvious area where this is being reported, so I think what's happening is that when the module gets its list of extensions and asks Drupal.org for the latest versions of those extensions, Drupal.org registers the usage. So there may need to be some work on Drupal.org's end to faciliate this.

Remaining tasks

Decide if it should be opt-in or opt-out. There's some discussion about this in 🌱 Telemetry initiative Needs review .

User interface changes

API changes

Data model changes

Release notes snippet

✨ Feature request
Status

Active

Version

11.0 πŸ”₯

Component
BaseΒ  β†’

Last updated about 1 hour ago

Created by

πŸ‡ΊπŸ‡ΈUnited States bkosborne New Jersey, USA

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @bkosborne
  • πŸ‡¬πŸ‡§United Kingdom AaronMcHale Edinburgh, Scotland

    This sounds like a good idea. More accurate usage data is a good thing.

    Decide if it should be opt-in or opt-out.

    My default position is opt-in, but we should definitely encourage sites to opt-in, highlighting the benefits of doing so, linking to a privacy statement, etc.

    Having said that, I personally wouldn't object to an opt-out strategy, as long as it was very clear to users that they can opt-out and the implications of staying "in" are clearly communicated.

    At the end of the day I think it comes down to how we communicate it and where we choose to place the option.

  • πŸ‡ΊπŸ‡ΈUnited States dww

    Indeed, there's no explicit telemetry as part of update.module. d.o "just" notices that a site has requested available update data for a specific project, which is how we "know" that project is in use.

    I'd be in favor of changing this, but it's not really a feature request for update.module and more a "build a whole new telemetry feature". Moving to base system for now, since there's not yet a better component for this request.

  • πŸ‡³πŸ‡ΏNew Zealand quietone
  • πŸ‡ΊπŸ‡ΈUnited States cmlara

    Opining from the other side of this:

    I don't enable the update module because of the telemetry reporting. This also prohibits project browser from being deployed.

    If the update module only requested a list of modules I would be more likely to allow it to be enabled.

    Polar opposite reason as to the original request, however equally tied to the same problem, mixing two different functionalities into the same code.

    Re opt-in/opt-out: I'm very much a fan of 'opt-in', we need to have consent for the data collection, opt-out does not give that consent.

  • πŸ‡¬πŸ‡§United Kingdom catch

    There is various configuration in update.module like which server to contact, how frequently etc. that would need to move to system.module if this was in core, which is the opposite of what we've been trying to do for years of moving things out of core/system into dedicated modules (path aliases, page cache etc.). So -1 to baking it in.

    We could have a 'telemetry' module that does the phone home, this would require removing the config from update.module and into the telemetry module (and adding a dependency), or duplicating the URL config (which could be confusing/go wrong). And the telemetry module wouldn't do anything except phone home so there is not really any reason to enable it. And a reasonable amount of work to move things around.

    On the other hand, we've got 🌱 Drupal 10 Core Roadmap for Automatic Updates Active and 🌱 Roadmap to experimental Project Browser in Drupal Core Active - those two modules depend on update module, and at some point might completely replace the UI of the existing update module.

    If we have 'update manager' and 'project browser' as two new modules, and 'update module' retains the phone home functionality but no longer provides the update status report UI and notification e-mails, then that could end up holding all the phone home code, that the other modules depend on, but without an extra step of moving things around compared to what will happen anyway.

    Locale also depends on update module (because it depends on the project listing API).

    So I think we should postpone this on update manager/automatic updates + project browser in core, and the UX consolidation that needs to happen around that, and see if we end up with an update API module by default, called update.module, which already exists. And then we can look at providing an option in update.module to send requests weekly even if the other modules aren't installed and that would allow sites to opt-in to telemetry if they want.

    Marking postponed and adding those two issues as related.

Production build 0.71.5 2024