Telemetry initiative

There are many great ideas on this issue for telemetry data points that we could collect. To make this more feasible, we should being by experimenting with collecting telemetry with as small scope as possible. For instance, we could create some leading indicators for the current lagging indicators. One of the indicators we're following is the number of Drupal sites reported by the update status module, which is a lagging indicator. However, there are leading indicators such as how many Drupal sites are being installed or how many Drupal composer projects are being initialized using composer create-project drupal/recommended-project drupal.

This data would be valuable when assessing the overall state of Drupal. If we could expand this to getting data on module installations too, we would have leading indicators for experimental modules as well, which would be extremely valuable for working on Drupal Core initiatives.

While there is a lot of other useful data that we would want to collect, starting with something small like this would make the scope more achievable. Once we have figured out this use case, we can move on to the next use case and add additional data points for the other proposed ideas.

Some progress on the performance information side of telemetry has been made in: 📌 Add open-telemetry/sdk and open-telemetry/exporter-otlp as dev dependencies Active

I was just chatting with @rkoller about how nice it would be to actually know how people are using the admin breadcrumbs. Would be so useful to know if folks are going to our help.

If there is a way to enable this so that we can learn more about how authors and admins use their sites it would be so valuable. So often we just have to make assertions based on what we think would be useful to these users. Sadly, extrapolations from developers is rarely as good as watching those trying to use their Drupal site.

I agree with lauriii in #44 that the scope of this needs to be reigned in. If we shoot for the moon, this initiative will never take off (that's not to knock any of the very good ideas I've read through above!!)

I'm here because I maintain a Drupal platform of 1,000+ websites and .

I don't have the update module enabled on any of these sites because the vast majority of the module's code (and it's a lot of code) is unrelated to sending the telemetry to Drupal.org, and it's for functionality I don't want or need. It's mostly around facilitating module updates/installs through the UI and reporting on modules that are out of date or have security issues. As a platform maintainer, I don't need that capability. I have other ways to monitor those concerns. As a platform maintainer, I try to keep unnecessary code off the platform as much as possible.

I know other platform maintainers (there's a lot of us in Higher Ed) that also don't have the update module enabled. We're collectively contributing to a massive under-reporting of project (module) usage on Drupal.org, all because the current code for collecting module telemetry is bundled with something we don't want.

So I feel the first step of launching this initiative is to separate the project usage reporting out of the update module and put it in core. Basically don't change any of the existing functionality of project usage reporting that Drupal.org already provides yet (I guess via the Project module?) We do that at a later time.

I see another user already created an issue about this #3199472: Improved data sharing with d.o → . I think that's a good place to start focusing the effort.

Actually that last issue has a broader scope and I didn't feel comfortable hijacking it entirely, so I created a new issue ✨ Moving project telemetry reporting from the update module into core Active as a child of this one.

I develop the OpenTelemetry contrib module → for Drupal. It is still in Alpha, but I hope it can help with generating interesting traces and metrics for receiving by Drupal Community as telemetry data.

To not insert into Drupal Core some telemetry-specific things, we can apply auto-instrumentation https://github.com/open-telemetry/opentelemetry-php-instrumentation and hook the needed functions in the wrapper.

And maybe eventually we will bring the opentelemetry as a Drupal Core module, that can be installed by default if the user opts in.

https://duanestorey.com/posts/down-the-rabbit-hole-a-deep-look-at-the-wo... is likely worth a read as it relates to Wordpress and the recent concern that Wordpress.org may have used telemetry data for less than ideal purposes (the Wordpress Engine Tracker site) raising questions about data collection in general by a CMS.

There is a lot of talk in this issue about collecting random data on a whim of someone had the idea it would be useful.

I would suggest that if this initiative ever does go forward that the first question asked regarding any data point should be "what problem will this solve in the next 3-6 months?" if you can not identify a specific concrete problem that can not be solved without the data point the collection is questionable.

I note this in other issues, even the collection of a site specific ID is enough to cause Update Manager to be disabled in many environments I work with. In general, the more data collection you add the less likely users are to be willing to share it.

@cmlara Very interesting article. I had no idea WordPress did that. I definitely agree that Drupal should only collect what it needs. I think that if users are given more granular control over which data is sent, they are more likely to allow it.